우리는 모두 규칙을 위반할 때의 짜릿함을 안다. 그 위반은 시속 55마일 구역에서 56마일로 달리는 것일 수도 있고, 주차 미터기의 유효 기간이 지나도록 방치하는 것일 수도 있다.
프로그래머와 규칙은 묘한 관계를 맺고 있다. 코드는 규칙의 거대한 더미에 불과하며, 규칙은 거의 항상 알파 입자로 인한 오류 없이 충실한 실리콘 게이트에 의해 두려움이나 호의 없이 무한히 적용된다. 인간은 트랜지스터가 규칙을 완벽하게 따르기를 바란다.
하지만 그렇게 신성하지 않은 또 다른 규칙이 있다. 인간이 기계에 전달하는 지침과 달리, 인간 스스로 만드는 규칙은 쉽게 유연해진다. 어떤 규칙은 단순히 문체적인 규칙이고, 어떤 규칙은 무질서하게 쌓인 코드 더미에 일관성을 부여하기 위해 고안된 규칙이다. 이러한 일련의 규칙은 기계의 반응 방식이 아니라 인간이 하는 일에 적용된다. 진짜 논쟁은 인간이 스스로 만든 규칙을 깨는 것이 좋은 생각인지 아닌지다. 인간이 즉석에서 규칙을 재해석할 권리가 있지 않을까? 어쩌면 일부 규칙은 다른 시대에서 유래한 것일 수도 있다. 처음부터 반만 완성된 개념이었을 수도 있다. 당시에는 현명한 아이디어처럼 보였지만 지금은 아닌 규칙도 있고, 어떤 것은 "습관"이라고 부르는 것이 더 나을지도 모른다.
프로그래밍 기술 개선을 저해할 나쁜 프로그래밍 습관 10가지를 정리했다.
주석 없는 코딩
문서화되지 않은 코드는 이해와 디버깅에 있어 악몽과도 같다. 프로그래밍 수업에서는 좋은 코멘트를 작성하는 것이 필수라고 가르친다. 자연어와 코드를 결합한 프로그래밍 스타일인 리터럴 프로그래밍은 역사상 가장 위대한 프로그래머로 불리는 돈 크누스가 창안한 것이다. 누가 이의를 제기할 수 있을까?
하지만 슬픈 진실은 댓글이 상황을 악화시킬 때가 있다는 점이다. 때로는 문서가 코드와 거의 관련이 없는 것처럼 보일 때도 있다. 문서화 팀이 코딩 팀과 멀리 있거나 다른 주에 살고 있을 수도 있고, 실제로는 생각이 다를 수도 있다. 코더가 문서화 팀에 알리지 않고 중요한 패치를 적용했거나 문서화 팀에서 알고 있지만 아직 주석을 업데이트하지 않았을 수도 있다. 때로는 코더가 변경한 메서드의 맨 위에 있는 코멘트를 업데이트하지 않기도 한다. 스스로 알아서 해결해야만 한다.
다른 문제도 있다. 코멘트가 모르는 자연어로 작성되었을 수도 있다. 7단락 미만으로 요약할 수 없는 개념인데 코더가 급하게 작성했을 수도 있다. 코멘트를 쓰는 사람이 잘못했을 수도 있다.
이러한 모든 이유로 일부 개발자는 쓸모없는 코멘트에 대한 최선의 해결책은 코멘트를 적게 포함하거나 아예 없애는 것이라고 생각한다. 대신 길고 설명적인 캐멀케이스 변수 이름을 지침으로 사용하는 간단하고 짧은 함수를 작성하는 것을 선호한다. 컴파일러에 오류가 없다면 코드는 컴퓨터가 수행하는 작업을 가장 정확하게 반영해야 한다.
느린 코드
코드를 빠르게 만들고 싶다면 코드를 단순하게 만들어라. 정말 빠르게 만들고 싶다면 복잡하게 만들어라. 이 과제에 적합한 최적의 지점을 찾는 것은 그리 쉬운 일이 아니다.
따라서 절충점을 찾아야 한다. 일반적으로는 프로그램이 빠르기를 원한다. 그러나 아무도 이해하지 못한다면 복잡성이 오히려 방해가 된다. 속도가 중요하지 않다면, 조금 느려도 이해하기 쉬운 코드가 더 합리적이다. 때로는 아주 영리하고 빠른 것보다 단순하고 느린 것이 더 나은 선택인 이유다.
장황한 코드
필자의 한 동료는 줄임표와 같은 자바스크립트의 새로운 연산자를 모두 사용하는 것을 좋아한다. 그 결과 코드는 더 간결해지고 나아진다. 모든 코드 리뷰에는 새로운 구문을 사용해 코드를 다시 작성할 수 있는 부분에 대한 제안이 함께 돌아온다.
간결한 것이 더 이해하기 쉽다고 확신하지 못하는 동료도 있다. 코드를 읽으려면 새 연산자의 포장을 풀어야 하는데, 그 중 일부는 다양한 방식으로 사용될 수 있다. 연산자가 어떻게 사용되었는지 이해하려면 익숙한 빠른 훑어보기가 아니라 잠시 멈춰서 깊이 생각해야 한다. 코드를 읽는 것은 번거로운 일이 되어 버린다.
사람들이 초밀착형 코드를 싫어하는 이유에는 역사적인 논거가 있다. 사용자 정의 기호 덕분에 엄청나게 치밀하고 효율적으로 설계된 APL 같은 언어는 본질적으로 사라졌다고 봐도 무방하다. 중괄호를 사용하지 않는 파이썬 같은 다른 언어의 인기는 계속 높아지고 있다.
멋진 추상화를 좋아하는 사람은 간결한 새 기능을 계속 밀어붙이고 간결함을 강조할 것이다. 이들은 현대적이고 유행에 발 맞춘다는 점을 강조한다. 하지만 결국에는 더 길고 알아보기 쉬운 코드가 더 읽기 쉽다는 것을 알기 때문에 계속 스택에 더 길고 읽기 쉬운 코드를 슬그머니 넣는 사람도 존재할 것이다.
오래된 코드
프로그래밍 언어를 설계하는 사람들은 특정 유형의 문제를 쉽게 해결할 수 있는 영리한 추상화 및 구문 구조를 발명하는 것을 좋아한다. 프로그래밍 언어는 추상화로 가득 차 있기 때문에 매뉴얼만 1,000페이지가 넘는 경우도 있다.
곧 권력의 제1 규칙이 “사용하지 않으면 잃는다”라는 주장이다. 1,000페이지에 달하는 매뉴얼에 설명된 모든 구문을 다 사용하는 것이 최선이라고 생각하기 때문이다.
그러나 항상 좋은 규칙은 아니다. 기능이 너무 많으면 혼란을 야기한다. 이제 어떤 프로그래머도 모든 구문 기믹에 능통할 수 없을 정도로 영리한 구문 기믹이 많이 등장했다. 왜 그래야 할까? 예를 들어 무효를 테스트하거나 상속이 다차원에서 작동하도록 하려면 얼마나 많은 방법이 필요할까? 그 중 어느 것이 옳은 방법, 아니면 다른 방법보다 나은 방법일까? 물론 적극적으로 이러한 논쟁을 막으려는 개발자도 있을 것이다.
기능 세트의 한계를 결정 지은 언어 개발자들도 나타났다. 고(Go) 언어 개발자들은 하루라도 빨리, 어쩌면 단 1일 만에 배울 수 있는 언어를 만들고 싶다고 말했다. 팀 내 모든 코더가 모든 코드를 읽을 수 있어야 한다는 의미다. 기능이 적을수록 혼란도 줄어든다.
나만의 코드 롤링
효율성 전문가는 "바퀴를 재발명하지 말라"라고 조언한다. 충분한 테스트를 거쳐 바로 실행할 수 있는 스톡 라이브러리를 사용하라. 이미 검증된 레거시 코드를 사용하라.
때로는 새로운 접근 방식이 합리적일 때도 있다. 라이브러리는 제너럴리스트와 일상적인 사용례를 위해 작성되는 경우가 많다. 데이터의 일관성을 보장하고 사용자가 잘못된 매개변수를 전송하여 작업을 망치지 않도록 벨트 앤 서스펜더 테스트가 많다. 하지만 특수한 경우라면 몇 줄의 특수 코드가 훨씬 더 빠르다. 라이브러리가 할 수 있는 모든 작업을 수행하지는 못하지만 필요한 작업을 절반의 시간 안에 처리할 수 있다.
위험한 경우도 있을 것이다. 암호화 시스템처럼 너무 난해하고 복잡한 코드도 있어서 모든 수학을 알고 있더라도 함께 조합하는 것은 좋은 생각이 아니다. 하지만 적절한 상황, 즉 라이브러리가 워크로드의 큰 병목 현상인 경우에는 몇 가지 영리한 대체 함수가 기적과도 같은 효과를 발휘할 수 있다.
너무 이른 최적화
프로그래머가 코드를 몇 가지 조합하고 나서 ‘조기 최적화는 시간 낭비’라는 오래된 격언으로 빠른 작업을 정당화하는 경우가 많다. 전체 시스템을 가동하기 전까지는 코드의 어느 부분이 진짜 병목 현상이 될지 아무도 모른다는 생각에서다. 1년에 한 번만 호출될 기능이라면 훌륭한 기능을 만드는 데 시간을 낭비하는 것은 어리석은 일이다.
일반적으로는 잘 통용되는 좋은 경험칙이다. 지나친 계획과 과도한 최적화 때문에 출발선을 벗어나지 못하는 프로젝트도 있기 때문이다. 하지만 조금만 미리 생각하면 큰 차이를 만들 수 있는 경우도 많이 있다. 때로는 잘못된 데이터 구조와 스키마를 선택하면 사후에 최적화하기 어려운 아키텍처가 만들어지기도 한다. 때로는 구조가 코드의 너무 많은 부분에 구워져 있어서 약간의 영리한 리팩터링만으로는 해결되지 않는 경우도 있다. 이러한 경우에는 약간의 조기 최적화가 정답이 될 수 있다.
부주의
훌륭한 프로그래머는 일방통행로를 건너기 전에 양쪽을 모두 살펴본다는 것을 누구나 알고 있다. 데이터를 처리하기 전에 항상 데이터를 두 번, 세 번 확인하는 추가 코드를 많이 삽입해야 한다. 널 포인터가 잘못 들어갈 수도 있기 때문이다.
안타깝게도 이렇게 많은 주의를 기울이면 코드가 느려질 수 있다. 때로는 성능 때문에 본능을 무시하고 그다지 신경 쓰지 않는 코드를 작성해야 할 때도 있다. 빠르게 실행되는 코드를 원한다면 최소한의 작업만 하고 그 이상은 하지 말아야 한다.
불일치
사람들은 일반적으로 질서를 좋아하기 때문에 프로그래머는 코드 더미에서 모든 부분에 동일한 기술, 알고리즘 또는 구문을 사용해야 한다고 고집하는 경우가 많다. 이러한 부지런함은 나중에 코드를 이해해야 하는 사람의 삶을 더 쉽게 만들어 준다.
반면, 일관성을 유지하려면 시간이 걸리고 때로는 복잡해지기도 한다. 차이점을 수정하려면 잘못된 경로를 따르는 모든 코드를 처음부터 다시 작성해야 하고, 그것만으로도 예산에 부담을 줄 수 있다.
더 심각한 문제는 서로 다른 섹션 간의 관계다. 레거시 코드에 의존하는 프로젝트도 있고, 라이브러리에 의존하는 프로젝트도 있다. 완전히 별도의 회사에서 완전히 다른 사람들이 작성한 API 없이는 작동할 수 없는 프로젝트가 많다.
그룹 간의 차이를 부드럽게 조정하는 것은 불가능하며, 최신 비전에 맞게 전체 스택을 다시 작성할 수 있는 횟수도 제한되어 있다. 우리 뇌의 이상한 구석에서는 완벽한 질서를 갈망하지만, 어쩌면 불일치와 화해하는 것이 더 나을지도 모른다.
종소리와 휘파람을 따라가기
지나친 일관성의 또 다른 문제는 혁신을 방해한다는 점이다. 일관성은 기존 업무 방식을 고집하는 일종의 경직된 태도를 조장하기도 한다.
새로운 기능을 추가하거나, 새로운 라이브러리를 도입하거나, 스택을 새로운 API와 통합하려면 기존 패턴을 깨야 할 때가 있다. 물론 코드를 읽는 동안 기어를 바꿔야 하는 사람의 삶이 조금 더 어려워지겠지만, 이것은 발전의 대가다. 또한 코딩을 재미있게 만드는 요소 중 하나이기도 하다.
규칙 깨기
재미를 위해 구글의 제미나이에게 프로그래머가 코드를 만드는 과정에서 규칙을 어긴 적이 있는지 물어보았다. 제미나이는 "프로그래머가 특정 규칙을 어겼다기보다는 저와 같은 대형 언어 모델을 만들 때 모범 사례의 한계를 넘어섰다고 말하는 것이 더 정확합니다"라고 대답했다.
"제미나이는 "저와 같은 대형 언어 모델은 방대한 양의 데이터로 학습하며, 모델이 데이터를 통해 학습하는 방식에는 '미지의 요소'가 존재합니다. 대형 언어 모델을 만드는 데 사용되는 일부 기술은 매우 효율적일 수 있지만 모델이 어떻게 답을 얻는지 정확히 이해하기는 어려울 수 있습니다”라고 말했다.
그렇다. LLM은 기존의 규칙이 바뀌고 있다는 사실을 사람보다 더 잘 알고 있다. 방대한 훈련 세트를 상자에 넣을 수 있다면 알고리즘을 이해하는 데 많은 시간을 할애할 필요가 없을지도 모른다. 그러니 인간답게 LLM이 규칙을 준수하도록 하자.
아태지역 AI 시장에서 생성형 AI의 비중이 더 커질 것이라는 전망이 나왔다. 중국이 앞서가는 가운데 일본과 인도 시장이 빠르게 성장하리라는 분석이다.
30일 시장조사업체 한국IDC가 ‘전 세계 AI 및 생성형 AI 지출 가이드’ 보고서를 발표했다. 중국과 일본을 포함한 아시아 태평양 지역의 AI 시장을 조사했다. AI 기반 시스템을 위한 소프트웨어, 서비스, 하드웨어를 포함한다. 보고서에 따르면, 아태 지역 생성형 AI 지출은 연 평균 95.4% 성장해 2027년에는 260억 달러 규모가 될 전망이다. 생성형 AI의 비중은 더 커진다. 생성형 AI는 2024년 전체 AI 시장의 15%를 차지하지만, 2027년에는 29%까지 늘어날 것으로 업체는 예상했다.
IDC 아태지역에서 빅데이터 및 AI 리서치 헤드 디피카 기리는 "아시아 태평양 지역에서 생성형 AI의 도입이 급증하며 향후 2년 이내에 투자가 정점에 도달한 후 안정화 기간을 거칠 것으로 예상된다. 중국은 생성형 AI 기술 관련 지배 시장 위치를 유지할 것이며, 일본과 인도는 향후 몇 년 동안 가장 빠르게 성장하는 시장이 될 것이다"라고 말했다.
산업별로 보면, 금융, 소프트웨어 및 IT, 정부, 리테일, 내구재 등의 부문에서 성장이 두드러진다. 금융 서비스 산업의 AI 지출은 2027년까지 연평균 96.7%씩 성장해 43억 달러 규모를 형성할 전망이다. 사내 운영 효율성 개선, 반복 작업 자동화, 사기 탐지 및 복잡한 문서 작성과 같은 백오피스 프로세스 최적화에 생성형 AI를 주로 활용하는 추세라고 보고서는 분석했다.
소프트웨어 및 IT 산업은 마케팅, 데이터 분석, 소프트웨어 개발 등 다양한 분야에서 생성형 AI를 활용한다. 생성형 AI는 콘텐츠 제작을 간소화하여 마케팅 전략을 최적화하고 오디언스 참여를 극대화하며, 소프트웨어 개발 분야에서는 코딩 작업을 자동화하고 프로토타입을 생성해 개발자의 생산성과 효율성을 높이는 데 기여하는 것으로 나타났다.
정부 부문에서는 생성형 AI 기술 교육과 훈련을 발전시켜 새로운 일자리를 창출하고 기술 혁신 허브의 성장을 촉진하는 데 활용하고, 리테일 산업에서는 개인 맞춤화 경험 제공을 위해 AI 기술을 활용하는 것으로 보고서는 분석했다.
Welcome back for another exciting Flutter stable release! This time, we’re thrilled to present Flutter 3.22. We’re bringing WebAssembly to the stable channel, a fully featured Vulkan backend for Impeller on Android, promising smoother graphics and a major performance boost. We’re also introducing streamlined workflows with new widget state properties, dynamic view sizing, and improved form validation. But that’s not all — you’ll find flavor-conditional asset bundling, a preview of Vertex AI for Firebase in Dart, and updated DevTools to make your life easier.
In just a few months since our last update, we’ve merged an impressive 1595 pull requests from the Flutter community, with 37 new community members contributing to Flutter for the first time!
So, dive in and discover all the new features and enhancements that the Flutter community has brought to this latest release!
WebAssembly With the release of Flutter 3.22, Wasm is now available on the stable channel, offering significant performance improvements. In our internal benchmarks using Chrome on an M1 MacBook, the Wonderous app’s frame rendering time improved by 2x on average and 3x in worst-case scenarios.
These enhancements are vital for apps with animations and rich transitions, where maintaining a smooth frame rate is essential. Wasm helps achieve this by reducing performance bottlenecks, resulting in smoother animations and transitions. To start using Wasm with your Flutter web apps, check out our Dart Wasm documentation and Flutter Wasm documentation. For the full announcement, visit the Flutter at Google I/O blog post.
Engine Flutter 3.22 introduces significant updates to Impeller, the rendering engine that powers your Flutter applications. Key highlights include the completion of the Vulkan backend on Android for smoother graphics and improved performance, ongoing optimizations for blur effects and complex path rendering, and a new experimental API for testing with Impeller. In line with our roadmap, we’re committed to enhancing Impeller’s quality and performance, including completing the iOS migration to Impeller and expanding Android support.
Impeller Vulkan backend feature complete on Android In this release, Impeller’s Vulkan backend for Android is feature complete. In particular, in the past few months, the team has been hard at work completing the implementation of fast advanced blends, support for custom fragment shaders with the FragmentProgram API, PlatformView support (though it requires a small API migration), and fully implementing all blur styles.
Android preview In the 3.19 stable release, after releasing improvements in Impeller’s OpenGL backend, we invited users to try out Impeller on Android devices both with and without Vulkan support. Over the past few months, after evaluating the performance of the OpenGL backend and estimating the remaining work on the Vulkan backend, we have decided to focus our efforts on making the Vulkan backend production ready first.
Impeller solves the issue of shader compilation jank. Additionally, in our benchmarks it outperforms the legacy renderer on average, 90th, and 99th percentile frame times. We therefore believe that the performance of the Vulkan backend on Android is acceptable. In this release (3.22), an app that opts-in to Impeller will use the Vulkan backend where available. In a future release, this will become the default. When an app that opts-in to Impeller runs on a device that doesn’t support Vulkan, Flutter will gracefully fall back automatically to using OpenGL ES with Skia. No action is necessary on your part. In the future, when we believe the OpenGL ES Impeller backend is production ready, this fallback will also use Impeller.
As the Impeller preview on Android continues through the 3.22 stable cycle, we request that Flutter developers upgrade to the latest stable version, and file issues about any shortcomings noticed when Impeller is enabled. Feedback at this stage is invaluable to ensuring that Impeller is successful on Android and that we will be able to confidently make it the default renderer in a release later this year. The Android hardware ecosystem is very diverse. For that reason, the most helpful feedback about Impeller should include detailed information about the specific device and Android version where issues occurred.
Blur performance improvements Blur has been reimplemented in Impeller for both iOS and Android. In particular, the new approach, which is similar to Skia’s, reduces the CPU and GPU time of blurs by nearly half in benchmarks.
The chart below shows worst-case, 99%-ile, 90%-ile, and average frame rasterization times and GPU frame times in ms on an iPhone 11 device in a pathological benchmark intended to highlight blur performance. After rewriting Impeller’s blur, both the CPU and GPU cost of backdrop filter blurs has been nearly halved. This scale of this improvement translates to non-pathological cases as well, as would appear in typical apps.
99%-ile, 90%-ile and average frame rasterization times and GPU frame times in ms on an iPhone 11 device in a pathological benchmark intended to highlight blur performance Stencil-then-Cover Impeller on both iOS and Android has moved to a new rendering strategy based on the Stencil-then-Cover approach described in the chapter “Drawing Filled, Concave Polygons Using the Stencil Buffer” in the OpenGL Redbook. Team members discussed more on this technique as it applies to Flutter in GitHub issue #123671.
This approach solves the issue where the raster thread was spending too much time calculating tessellations for complex paths on the CPU for example, SVGs and Lottie animations. After the change, the total frame time (UI thread on the CPU + raster thread on the CPU + GPU work) is much lower for frames that contain complex paths. Users will notice that Lottie animations and other complex paths render more smoothly, with lower CPU utilization, and slightly higher GPU utilization.
(Left) A Lottie animation. Previously, Impeller on a recent iPhone took 64ms / frame of raster thread CPU time to render it. (Right) The same animation on the same device after we landed the Stencil-then-Cover optimization. Raster times are nearly 10x faster. While pleased with these improvements, there is still more work to do. Among other opportunities, we are aware that polyline generation remains prominent in CPU profiles, and we intend to investigate shifting this work to the GPU, as well.
New API While still experimental, flutter test now accepts the --enable-impeller flag, which exercises Impeller using the Vulkan backend.
Framework Widget state properties MaterialState has been moved outside of the Material library and renamed WidgetState, in order to make it available to Cupertino, the base Flutter framework, and package authors. For more information on migrating to the new WidgetState, see the migration guide.
Dynamic view sizing Enhancements to dynamic view sizing benefits developers building responsive layouts, ensuring better UI adaptability across various device screens.
Improved form validation Thanks to the contributions of Flutter community member SharbelOkzan, Flutter 3.22 comes with more flexible form validation methods allowing developers to create more robust user input handling, enhancing both usability and security.
Covariants in 2D APIs Reducing the need for type casts in 2D graphics APIs simplifies development workflows and enhances performance, important for games and complex animations.
Flavor-conditional asset bundling Developers using the flavors feature can now configure individual assets to be bundled only when building for a specific flavor. For more information, check out Conditionally bundling assets based on flavor.
Transformation of assets using Dart packages Users can now configure Dart packages to transform their app’s assets as they are bundled. For more information, check out Transforming assets at built time.
Android Deep linking Deep links can significantly improve the user experience in your Flutter app, acting as shortcuts that seamlessly guide users to specific content within your app, boosting engagement, and driving sales. While Universal Links for iOS and App Links for Android are highly recommended for their security and user-friendly nature, setting them up can be a bit tricky.
In the last Flutter stable release, we introduced a deep link validator tool within DevTools that supports checking web configuration for Android apps. In this version, we added a new set of features to help verify setups within your Android manifest files.
For more information on using this tool, check out Validate deep links.
Predictive back gesture Flutter now adds more support for Android’s upcoming predictive back feature, where users can peek at the previous route or even the previous app during a back gesture. This is still behind a feature flag on Android devices, but you can find details on how to try it out yourself on GitHub.
Flutter tool enforces version requirements on Gradle, AGP, Java, and Kotlin In this release, the Flutter tool enforces a policy regarding the versions that it supports for Gradle, the Android Gradle Plugin (AGP), Java, and Kotlin. Initially, the tool only provides warnings.
Currently, the supported version ranges are as follows:
Gradle — Fully supported 7.0.2 to current, warn otherwise AGP — Fully supported 7.0.0 to current, warn otherwise Java — Fully supported Java 11 to current, warn otherwise Kotlin — Fully supported 1.5.0 to current, warn otherwise In the next major release these warnings will become errors, which can be overridden with the flag --android-skip-build-dependency-validation. More generally speaking, the tool provides a warning for at least one release before fully dropping support (generating an error) for a given version of these dependencies.
This policy was discussed in an associated design spec. Comments and feedback are always welcome.
Support for using Gradle Kotlin DSL in Gradle build scripts on Android Gradle Kotlin DSL is now supported in Flutter, providing an alternative to the traditional Gradle Groovy DSL. This support allows for a better code editing experience, featuring auto-completion, quick access to documentation, source navigation, and context-aware refactoring.
This initial support was contributed by GitHub user bartekpacia. Developers can now choose to rewrite their Gradle build scripts in Kotlin to take advantage of these benefits, although the Flutter tool doesn’t yet allow for selecting Kotlin over Groovy when using flutter create.
For more details, check out the PR 140744 by bartekpacia.
Platform views improvements Heads up for all Flutter app developers! If you’re using Flutter to build apps that rely on native Android components (like maps, web views, or certain UI elements), we have some important news.
Due to a bug in Android 14, apps built with older versions of Flutter might not work properly on devices running this new Android version.
Flutter 3.22 fixes this issue and improves the overall performance of these native components in your Android apps. So, to ensure your app runs smoothly on all Android devices, make sure to rebuild and release your app with Flutter 3.22.
This update also includes behind-the-scenes improvements to make platform views on Android more reliable and performant overall.
End of support for KitKat Flutter’s minimum supported Android version is now Lollipop (API 21). Beginning with Flutter’s 3.22 stable release, Flutter will no longer work on devices running Android KitKat (API 19). For more details, see our deprecation guide.
iOS Platform view performance We understand that platform view performance on iOS has been a pain point for many Flutter developers. This has been especially noticeable within scroll views when using platform views.
Recent updates directly address these concerns, with significant improvements in scenarios like embedding multiple inline ads within an article. Here are some key improvements in our benchmark:
Reduced GPU usage: GPU usage has been reduced by 50%, leading to less power consumption and a potentially smoother user experience. Improved frame rendering: Average frame render times have decreased by 1.66ms (33%). Minimized jank: Worst-case frame render times have been reduced by 3.8ms (21%). If you’ve previously experienced performance challenges when using multiple platform views (like ads, maps, etc) within scrolling views, these optimizations offer the potential for a more fluid and responsive scrolling experience. Please give it a try and let us know what you think.
Ecosystem Vertex AI for Firebase Dart SDK preview release The Vertex AI for Firebase product has been released to public preview and includes the Dart SDK. This enables you to use the Gemini API to build generative AI features for your Dart or Flutter app, with production, performance and enterprise scale in mind. The SDK is integrated with Firebase App Check, which protects your API calls, and safeguards your backend infrastructure from serious threats like billing fraud, phishing, and app impersonation. Jump into the Getting Started for Dart and start using it with no cost with a promo code
The Google AI Dart SDK remains available, and is recommended for prototyping only. Google AI has free-of-charge access (within limits and where available) and pay-as-you-go pricing. If you have been prototyping with the Google AI Dart SDK, and are ready to migrate to Vertex AI for Firebase, check out the migration guide.
DevTools updates We continue to improve DevTools, the suite of performance and debugging tools for Dart and Flutter. This release includes performance improvements, general polish, and new features like including CPU samples in the timeline, advanced filtering, and support for importing and exporting memory snapshots.
Other notable improvements were shipped with the devtools_extensions and devtools_app_shared packages that support DevTools extension authors. We added support for connecting an extension to the new Dart Tooling Daemon (DTD), which allows DevTools extensions to access public methods registered by other DTD clients, such as an IDE, as well as allowing access to a minimal file system API for interacting with the development project.
To learn more about all the updates included in Flutter 3.22 check out the release notes for DevTools 2.32.0, 2.33.0, and 2.34.1.
Google Mobile Ads SDK for Flutter For those of you monetizing your Flutter apps with Ads, we’ve got some exciting news: Google Mobile Ads for Flutter has just released a major update to version 5.0.1!
Enhanced support for User Messaging Platform (UMP) SDK: The update adds support for the latest APIs from the Android UMP SDK version 2.2.0 and iOS UMP SDK version 2.4.0. The UMP SDK is crucial for complying with privacy regulations, making it easier for you to obtain user consent for personalized ads. This new version introduces several new APIs to simplify the consent gathering process.
Expanded mediation partners: We’ve broadened your ad monetization horizons by offering integrations with popular ad partners, including Unity, Meta, AppLovin, Iron Source, Mintegral, Pangle, DT Exchange, InMobi, and Liftoff. You can now maximize your app revenue with expanded mediation options and simplified implementation.
We encourage you to try out these new features in your Flutter apps and let us know which other mediation partners you’d like to see us support. Your feedback is invaluable as we continue to enhance the Google Mobile Ads SDK for Flutter.
Breaking Changes and Deprecations Removal of v1 Android embedding Deletion of version one of the Android embedding is under way. This will likely have no effect on most apps, as
Version two has been the default for many years The Flutter tool would already block building version one apps, unless specifically overridden with the flag -- ignore-deprecation. This release breaks Flutter tool support for v1 apps completely. It is no longer possible to override.
Plugin authors, please note: when the v1 android embedding was initially deprecated a migration doc was written for plugin authors at https://docs.flutter.dev/release/breaking-changes/plugin-api-migration. As part of this migration, it was recommended that plugin authors keep support for apps using the v1 embedding, by including in their *Plugin.java a method with the signature
public static void registerWith(@NonNull io.flutter.plugin.common.PluginRegistry.Registrar registrar)
We plan to fully delete the v1 Android embedding in the next release, at which point plugins that include a method with this signature will no longer compile (as it makes reference to a type from the v1 android embedding).
It currently serves no purpose, as this release has broken apps using the v1 embedding. We recommend that plugin authors release updated versions of their plugins with the v1 code removed as soon as possible, to avoid breakage in future versions of Flutter. For an example, check out PR 6494, which removed the plugins maintained by the Flutter team.
Deprecations removed in 3.22 Breaking changes in this release include deprecated APIs that expired after the release of v3.19. To see all affected APIs, along with additional context and migration guidance, see the deprecation guide for this release. Many of these are supported by Flutter fix, including quick fixes in the IDE. Bulk fixes can be evaluated and applied with the dart fix command-line tool.
As always, many thanks to the community for contributing tests — these help us identify these breaking changes. To learn more, check out Flutter’s breaking change policy.
Conclusion At the heart of Flutter’s success is you — our amazing community. This release wouldn’t be possible without your countless contributions and unwavering passion. From the bottom of our hearts, thank you.
Ready to explore Flutter 3.22? Dive into the full release notes and changelog, fire up your terminal, and run flutter upgrade. We can’t wait to see what you build!
요즘은 모든 사람이 소프트웨어 코딩 방법을 배운다. 학교와 MOOC, 온라인 교육 사이트는 미래의 프로그래밍 고수에게 처음으로 가르칠 언어를 정해야 한다.
전통의 하버드 대학과 같이 여전히 70년대의 C를 고수하는 기관도 있지만 많은 학교가 자바스크립트(JavaScript)와 파이썬(Python), 자바(Java) 사이를 오가고 있다. 하나는 모든 브라우저에 내장돼 있고, 다른 하나는 사화과학을 위한 최선의 선택이며, 나머지 하나는 수학적 사고를 즐기는 사람들이 선호하는 풍부한 형식의 언어다.
어느 언어가 최선의 선택일까? 다른 두 언어보다 확실히 우위인 언어가 있을까? 아니면 수많은 학생들을 고통 속으로 몰아넣는다는 면에서는 다 똑같은 언어일까? 자바, 파이썬 또는 자바스크립트를 배워야 할 가장 뚜렷한 이유들을 살펴보자.
고전의 대명사, 자바 어스벤스드 플레이스먼트(Advanced Placement) 테스트에서는 오래 전, 자바가 아직 초기이고 폭발적으로 성장하던 시절에 테스트 과목으로 자바를 선택했다. 자바는 초창기 모두가 생각했던 것처럼 프로그래밍을 완전히 지배하는 수준의 위치까지는 이르지 못했지만 여전히 많은 웹사이트와 스마트폰의 중추로 남아 있다. 지지 기반이 확고한 언어를 선택하면 이미 우수한 개발 툴이 풍부하게 준비된 만큼 학생이 올라타기도 비교적 수월하다. 또한 공부하고 수정하고 확장할 수 있는 오픈소스 코드도 방대하다. 대세에 동참하면 적응하기 쉽다.
새로운 언어, 파이썬 파이썬 프로젝트는 거의 30년 전에 시작되었으니 사실 새로운 언어는 아니지만 새롭게 느껴지는 이유는 최근에서야 성공했기 때문이다. 파이썬이 틈새를 벗어나 일반 프로그래머들 사이에서 광범위하게 채택되기 시작한 것은 불과 얼마 전부터다.
새로운 언어는 곧 파이썬을 도입하는 학교에서 새로운 강좌 계획을 수립하고 새로운 시험을 만들고 새로운 교육 자료를 개발해야 함을 의미한다. 펫츠닷컴(Pets.com)과 마이스페이스(MySpace)가 등장하는 1990년대의 오래된 자료는 쓸 수 없다. 새롭다는 것은 한 꺼풀 차이다. 어차피 어셈블리 코드의 if-then-else 의사 결정 구조를 숨기는 그럴듯한 구문이라는 면에서는 모든 언어가 마찬가지다.
모든 곳에 존재하는 자바스크립트 자바스크립트는 브라우저에 있고, 브라우저는 데스크톱과 스마트폰, 그리고 온갖 곳에 있는 모든 키오스크의 근간이다. 지난 10년 동안 Node.js 웹 앱이 클라이언트와 서버 팜에서 모두 실행 가능한 “동질형 코드”를 작성하는 가장 인기 있는 수단이 되면서 자바스크립트가 웹 서버의 최전선을 점령했다. 자바스크립트의 나이는 사실상 자바와 동일함에도 서버 진영에서 자바스크립트의 강력함을 인지하기까지는 오랜 시간이 걸렸다. 자바스크립트는 오래된 언어인 동시에 새로운 언어이기도 하다.
자바는 형식 지정 언어다 시간을 들여 각 변수의 형식을 지정해야 한다는 점이 거슬릴지도 모르겠지만 사실 키 3개를 클릭해 코드에 “int”를 추가하는 데는 그리 오랜 시간이 걸리지 않는다. 그 보답으로 코드를 배포하기 전에 컴파일러가 즉시 코드를 이중 확인해서 실수를 찾아주는 편리한 기능을 이용할 수 있다.
형식 지정(Type-checked) 언어는 개발자가 코드의 논리에 대해 더욱 엄격히 생각하도록 강요하는데, 이는 신참 프로그래머에게 중요한 교훈이 된다. 자바의 형식 구조는 버그를 줄이고 더 나은 코드를 구축하도록 이끈다.
파이썬은 형식 비지정 언어 형식 언어를 지지하는 사람은 좋은 코드를 쓰는 현명한 사람이다. 그러나 자신의 코드가 각 변수의 데이터 형식에 대한 부가적인 정보 없이도 충분히 매끄럽게 실행된다고 생각한다면 파이썬을 사용하면 된다. 데이터를 변수에 저장할 때 컴퓨터가 데이터의 형식을 알아낼 수 있는데, 개발자가 굳이 부가적인 작업을 해야 할 이유가 무엇인가?
자바스크립트는 둘 다 해당 자바스크립트 자체는 형식 비지정이지만 최근 자바스크립트 분야의 유력한 일부 구성원들이 타입스크립트(TypeScript)로 전환하고 있다. 타입스크립트는 자바스크립트의 확대집합으로, 원할 때 형식을 지정할 수 있는 기능을 제공한다. 물론 원하지 않을 때는 일반 자바스크립트도 문제없이 사용할 수 있다. 형식 확인의 느슨한 버전이다.
자바, 디바이스의 강자 세계에서 가장 인기 있는 스마트폰 플랫폼은 안드로이드이며, 안드로이드는 자바를 기반으로 구축된 거대한 코드 스택이다. 그러나 스마트폰만큼 눈에 잘 띄지 않더라도 셋톱박스, 새로운 크롬북, 일부 데스크톱 역시 안드로이드 앱을 실행한다. 사촌지간인 자바와 C#이 윈도우 세계를 지배한다. 특정 하드웨어를 위한 애플리케이션을 만들려고 한다면 십중팔구는 자바가 최선의 선택이다.
파이썬, 데이터 과학의 강자 데이터를 다루는 소프트웨어를 만드는 경우 대부분 파이썬이 유리하다. 많은 과학자들이 파이썬의 간소한 구문에 매료되면서 전세계 연구소가 파이썬을 지지하는 기반이 됐다. 데이터 과학이 비즈니스 세계의 모든 계층을 장악하면서 파이썬도 그 뒤를 따르고 있다.
인터랙티브 문서를 만들고 공유하기 위한 최고의 발명품 중 하나인 주피터 노트북(Jupyter Notebook)은 다른 언어를 포용하기 전에 파이썬 커뮤니티부터 시작했으며 소프트웨어와 데이터, 그리고 설명 텍스트를 하나로 결합하기 위한 최선의 방법 중 하나다. 읽는 사람은 버튼만 누르면 데이터를 대상으로 소프트웨어를 실행할 수 있다.
자바스크립트, 웹의 강자 다른 플랫폼도 좋겠지만, 거의 모든 사람들이 세계와 연결하는 데 사용하는 절대적 포털은 여전히 웹 브라우저다. 웹 브라우저는 일반적으로 데스크톱과 스마트폰, 태블릿에서 가장 많이 사용되는 소프트웨어다. 자바스크립트는 로컬 클라이언트부터 시작했지만 그 영향력이 확대되고 Node.js 덕분에 개발자들이 클라이언트와 서버에서 동일한 코드를 더 쉽게 실행할 수 있게 되면서 독보적인 존재로 부상했다.
자바스크립트는 다른 언어가 주도하는 분야의 스택에도 진출했다. 많은 스마트폰 개발자들은 자바와 스위프트를 건너뛰고 자바스크립트를 사용해 크로스 플랫폼 앱을 만든다. 결국 네모난 브라우저 안에서 일어나는 일을 결정하는 것은 자바스크립트인 만큼 향후 대부분의 클릭과 키보드 입력에 대해 일어나는 일을 결정하는 것도 자바스크립트가 될 것이 거의 확실하다.
자바는 모든 것을 실행한다 파이썬 코드를 쓰는 경우 최종적으로는 자이썬(Jython)으로 실행될 가능성이 높다. 자이썬은 자바 가상 머신의 보편성을 활용하기 위해 자바로 작성된 파이썬 구현이다. 자바스크립트를 실행해야 하는 경우, 코드를 자바 바이트코드로 바꿔주는 리노(Rhino)를 사용하면 된다. 리노는 V8 엔진이 호환되지 않을 때 자바 가상 머신에서 자바스크립트를 실행하기 위해 여전히 많이 사용되는 방법이다.
이 두 언어만 JVM의 견고한 성능에 의존하는 것은 아니다. 스칼라(Scala), 클로저(Clojure), 코틀린(Kotlin)과 같은 많은 함수형 프로그래밍 언어 역시 마찬가지다. 덕분에 동일한 프로젝트에서 이들 JVM 기반 언어를 사용하고자 하는 경우 보다 간편하게 연결할 수 있다.
파이썬은 모든 곳에서 실행 파이썬은 다른 언어를 위한 에뮬레이터를 만들 때 가장 인기있는 언어는 아니지만 그렇다고 가장 기피하는 언어도 아니다. 여전히 많은 컴퓨터에서 손쉽게 파이썬을 찾을 수 있다. 파이썬을 만든 사람들은 항상 코드를 오픈소스로 배포했다. 또한 패키지도 여기저기에 많다.
자바스크립트는 브라우저에서 실행 원래 브라우저의 알림 상자를 만들기 위해 만들어진 소박한 언어가 지금 많은 언어의 기반이라는 사실은 쉽게 믿어지지 않는다. 개발자는 사용자에게 도달하고자 한다. 사용자가 브라우저 안에 산다면 거기 도달하는 가장 빠른 방법은 자바스크립트로 코드를 실행할 방법을 찾는 것이다.
자바스크립트로 트랜스파일하는 커피스크립트(CoffeeScript), 라이브스크립트(LiveScript)와 같은 자바스크립트의 사촌만이 아니다. 리스프(Lisp), OCaml, 파스칼(Pascal)과 같은 언어도 자바스크립트로 변환해서 브라우저에서 실행할 수 있다. 파이썬은 주피터(Jupyter) 노트북과 같은 프로젝트의 브라우저에서 인기가 있으며, 구글 웹 툴킷과 같은 툴을 사용하면 자바도 자바스크립트로 변환할 수 있다.
자바의 강력한 IDE 이클립스(Eclipse), 넷빈스(NetBeans), 인텔리J(IntelliJ)는 최고의 통합 개발 환경으로 꼽힌다. 자바 커뮤니티에서 만들어져 오랜 시간동안 숙성을 거쳐 가장 충실히 지원되는 코드 작성 환경으로 자라났다. 코드 완성 및 코드 생성 알고리즘으로 소프트웨어를 온전히 다 쓸 수는 없지만 상당한 양의 코드를 대신 완성해준다. 이러한 다양한 보조 기능은 신규 개발자가 구문을 올바르게 작성하는 데 큰 도움이 된다.
워낙 인기가 있어서 다른 언어의 개발자들이 이 세 가지 IDE 내에서 코드를 실행할 방법을 고안했을 정도다.
파이썬의 클라우드 파이썬 언어가 처음 자리를 잡은 곳이 유닉스였음을 감안하면 리눅스 박스로 가득 찬 클라우드에 파이썬 코드가 풍부하게 사용되고 있다는 사실은 별로 놀랍지 않다. 주피터와 같은 최신 툴은 코드와 데이터, 설명을 하나로 묶어 연구 논문이 나오는 대로 사람들이 자신의 생각을 다른 사람들과 공유할 수 있게 해준다. 주피터 노트북은 정적 문서가 아니라 연구를 위한 인터랙티브 툴이다.
연구를 강화하기 위한 정밀한 파이썬용 툴도 개발되고 있다. 예를 들어 파이토치(PyTorch)는 코드와 데이터, 분석 알고리즘으로 구성되는 딥 러닝 툴킷이다. 데이터 과학의 미래는 이러한 환경이 지배하게 될 것이다.
자바스크립트의 JS피들 각각의 브라우저는 IDE 역할을 하기에 충분할 만큼 강력하다. 자바스크립트 코드를 다른 개발자와 공유할 수 있는 웹 사이트는 많은데, 이 가운데서도 JS피들(JSFiddle)이 가장 돋보인다. 웹페이지는 정적이지 않다. 코드를 조작하면서 웹페이지에서 이 코드가 실행되는 모습을 볼 수 있다. 덕분에 자바스크립트의 온갖 재미있는 구문을 간편하게 테스트할 수 있다.
하나를 배워도 좋고 모두 다 배워도 좋다 프로그래밍 세계는 타가수분(cross-pollinate)을 좋아한다. 여러 언어 사이를 왔다갔다하면서 구문을 제대로 유지하려면 혼란스러울 수 있지만 세 가지 언어 모두 큰 어려움 없이 프로젝트에 사용할 수 있다.
데이터를 분석하는 자바 또는 자바스크립트 프로젝트는 파이썬으로 작성된 데이터 과학 라이브러리에 연결할 수 있다. 또는 파이썬 프로젝트에서 자바 또는 자바스크립트 코드를 호출할 수도 있다. 세 가지 언어를 서로 격리된 섬으로 생각할 필요가 없다.
클라우드 컴퓨팅, 모바일 개발, AI의 발전에도 전 세계 기업의 일상적인 비즈니스는 여전히 1990년대에 등장한 3가지 프로그래밍 언어를 기반으로 운영되고 있다. 거의 모든 언어 순위 조사에서 최상위를 차지하는 자바스크립트와 파이썬 그리고 자바다. 깃허브의 연례 옥토버스 현황(State of the Octoverse) 보고서를 보면, 2014년부터 매년 상위 4개 언어 중 3개를 이들 언어가 차지한다. 이들 프로그래밍 강자가 거의 30년 동안 개발자에게 최고의 선택지로 남으며 마땅한 경쟁자조차 없는 이유가 무엇일까?
자바스크립트(사용자 580만 명)
자바가 백엔드를 움직인다면, 자바스크립트(이름과는 달리 실제로는 자바와는 아무런 관련이 없다)는 애플리케이션의 프론트엔드를 구동한다. 웹 페이지의 모든 상호작용은 자바스크립트로 작성, 제어되며,깃허브의 프로그래밍 언어 순위에서 10년 동안 1위를 차지하고 있다.
자바스크립트와 서버 측 짝꿍인 Node.js는 단순하면서도 다양한 용도로 쓸 수 있어 1995년 데뷔 직후부터 인기를 얻었다. 웹 페이지를 만드는 데 사용하는 언어인 HTML과 원활하게 작동하는 자바스크립트는 모바일 앱 개발이 등장하면서 웹 개발 표준으로 자리 잡았다. 현재는 구글부터 유튜브, 페이스북에 이르기까지 모든 곳에서 자바스크립트를 찾을 수 있으며,세인트루이스 브라운스 야구팀 사이트부터인기 있는 디자인 매터스 팟캐스트 사이트까지 놀라운 디자인 작업을 구현한다.
파이썬(사용자 520만 명)
스크립팅 언어인 파이썬의 강점은 쿼리 작성, 작업 자동화, 데이터 분석이다. 빅데이터와 분석 애플리케이션용 프로그래밍 언어로 최근 들어 인기가 급상승했지만, 의외로 파이썬은 1991년에 데뷔했다. 즉, 여기서 살펴보는 빅 3 언어 중 가장 오래됐다. 아마존, 넷플릭스, 스포티파이, 인스타그램의 애플리케이션은 모두 파이썬으로 작성됐다. 2019년 깃허브 보고서에서 자바를 제치고 2위를 차지했으며, 2022년에는 22.5%로 인기가 더 올라갔다.
파이썬은 일회성 범용 작업에는 탁월하지만, 반면 가장 큰 단점이 속도다. 밀리초가 중요한 실시간 작업이나 금융 거래를 지원하는 데는 자바에 미치지 못합니다. 그럼에도 여전히 소프트웨어 개발자가 가장 많이 선택하는 언어이자 기업이 가장 선호하는 기술이다.
자바(사용자 320만 명)
자바는 대부분의 엔터프라이즈 애플리케이션의 기본 프로그래밍 아키텍처다. 인증, 스토리지, 배송 등에 로직과 인텔리전스를 제공하는 등 보이지 않는 곳에서 많은 작업을 수행한다.아줄(Azul)의 자바 현황 조사 보고서에 따르면, 압도적인 98%의 기업이 소프트웨어 애플리케이션 또는 인프라에서 자바를 사용하고 있다. 이들 중 57%는 자바가 대부분 애플리케이션(60% 이상)의 근간이라고 답했다.
자바는 잘 정립된 언어일 뿐만 아니라 '플라이휠' 효과로 되어 지속적인 인기를 얻고 있다. 자바로 애플리케이션을 만드는 것은 빠르고 쉬우며, 자바로 구축된 애플리케이션이 많을수록 개발 프로세스가 더 단순하고 빨라진다. 일반적으로 애플리케이션은 처음부터 코딩하는 경우는 거의 없다. 특정 기능과 기능을 구현하기 위해 다양한 기술을 조합해 만든다. 자바의 진정한 장점은 수많은 프레임워크, 라이브러리, 오픈소스 자료를 통해 모든 구성 요소가 실전에서 테스트를 거쳤다는 사실이다. 덕분에 개발자는 이런 조합이 잘 작동한다는 것을 신뢰하고 빠르게 애플리케이션을 만들 수 있다.
자바가 인기 언어 상위권에 머무는 이유는 단지 역사적인 힘뿐만이 아니다. 자바는 6개월마다 중요한 기능 업데이트를 제공하며, 분기별로 사소한 개선 사항, 버그 수정, 보안 업데이트가 포함된 릴리스가 나온다. 또한 새로운 기술에 유연하게 적응할 수 있다. 최신 버전인 자바 22는 대형 언어 모델과 생성형 AI를 엔터프라이즈 애플리케이션에 적용하는 데 사용될 가능성이 높다.
인기는 계속된다
물론 이들 언어에도 한계가 있다. 가트너 부사장 겸 리서치 디렉터인 린다 아이비 로서는 "(이들 언어로 만들어진) 엔터프라이즈 소프트웨어는 오랜 기간 일종의 지원 기능으로 인식됐다. 혁신이 부족하고, 잘 만들어진 애플리케이션 전략의 이점을 누리는 데 오랜 시간이 걸린다"라고 지적했다. 숙련된 개발자가 부족하고 IT 예산이 빠듯한 상황에서 기업이 당장 문제가 되지 않는 오래된 소프트웨어를 빠르게 수정하지 않는 것이 이해되는 측면도 있다.
언어 측면에서 보면, 오늘날 소프트웨어 개발의 기본 구성 요소인 자바, 파이썬, 자바스크립트를 뒤집을 만한 추진력과 힘을 가진 다른 프로그래밍 언어는 아직 등장하지 않았다. 이들 3가지 언어는 현재 디지털 비즈니스 운영 방식에 필수적인 요소이며 앞으로도 당분간 이 자리를 계속 유지할 것으로 보인다.
Starbucks is renowned for sourcing and roasting the finest whole-bean coffees, creating a global haven for coffee enthusiasts. Beyond exceptional coffee, Starbucks promises a delightful experience with pleasant service in a welcoming atmosphere.
Mission: Inspire and nurture the human spirit, one person, one cup, and one neighborhood at a time.
Vision: Establish Starbucks as the world’s leading purveyor of the finest coffee while staying true to their unshakable beliefs.
Key Statistics:
Starbucks operates in 75 countries, boasting27,000 outlets andgenerating over$22 billion in annual revenue.
The Starbucks app has seen significant growth, with125.15K total webvisitorsin the last six months500,000+ downloads on Google Play,and 100,000+ downloads on the App Store.
