Coming to Expo: a new open-source repo, TypeScript, best-in-class APIs, custom native code, more platforms, and much more
Expoが新しくブログ記事を公開したんだけど、オープンソース化したりTypeScript対応だったりとかv31でどういう感じにするかとか諸々指針を公開したっていう。
なので今日はそれをざっくりかいつまんだ翻訳的なお話をば。
■はじめに
Expo developers include a wide variety of people making apps with Expo in different ways. To learn more about the most popular apps made with Expo we talked to developers and looked at production apps and found that most of them are made by professionals as part of a business. People who use Expo for business use it sometimes everyday and rely on it in part for their livelihoods as professional programmers.
Over the past few months we’ve been working on features and structural changes to the Expo platform to better serve skilled professionals and give them the agency to build high-quality apps with pride. Today, we’d like to share with you: how Expo is changing to increase agency for developers, our focus on quality and rigor, improvements to the developer experience, and some of the future direction of the Expo project.
Expoで作られた中で人気のあるアプリとか、プロダクションアプリを見てみるとほとんどがビジネスとして作られてるから、仕事としてやってるプログラマが毎日使ってたりするよねとのこと。
Expoがどう変わっていくかとか、開発者に気持ちよく使ってもらうために品質や厳しさに焦点をあてたりとか、Expoを将来どうするかということについて述べるよ的な。
Sections
・Developer Agency: Open-Source-First Development, One License (MIT), Self-hosted JS, Self-built Standalone Apps, and Custom Native Modules
・Craft, Quality, and Rigor: High-quality APIs, Stability, Robust Tests, React Navigation 3, and Beyond Android and iOS
・A Professional Developer Experience: Expo CLI 2, TypeScript, Single-SDK Builds, and Teams
・The Future: SDK 31 and Modern JSC; Background APIs; 64-bit APKs; Paid Services; and Speed, Quality, Universality, Stability, and Flexibility
目次
・開発にあたって：オープンソースだったり、MITにしたり、JSのセルフホストだったり、自分でスタンドアローンをビルドできるようになったり、カスタムでネイティブモジュールを作れたり。
・技術品質厳しさ：ハイクオリティなAPIや、安定性や、堅実なテストだったり、React Navigation v3だったり、AndroidやiOS以外にも。
・よりよい開発体験：expo-cli v2だったり、TypeScriptだったり、シングルSDKでビルドだったり、チーム対応だったり。
・将来的に：SDK31とかモダンなJSC(JavaScript Core)だったり、バックグラウンドAPI、64bit APK対応、スピードとかクオリティとか安定さとか色々と対応するためのExpo年間プランとか。
■開発にあたって
When working on apps, developers look to build the features they envision for the app on a timeline they choose. Achieving these goals is largely up to a developer’s ability and decisions but sometimes a platform or technology can be a bottleneck. In Expo’s case, we see that skilled developers often wish it were easier to write custom native code or contribute back to Expo. We also receive many requests to add more APIs. Some developers also have asked to build their app binaries on dedicated hardware or to host their app JS and assets on their own servers. A common thread across these scenarios is that developers are blocked on Expo in different ways; to address these issues sustainably, we want for skilled developers to have the agency they need to build high-quality apps and for Expo not to be a bottleneck. We have made several ad hoc and systemic changes in this vein and plan to work on several more.
ネイティブコードをカスタムしたいとか、より多くのAPIを追加するとか、アプリのバイナリとかJSとかを独自のサーバにホスティングしたいとかあったりするけど、これらに対応するためにシステムとか変更していきたいと思っている的な。
- オープンソース化
One of the major structural changes we made was to move development of the Expo client software from a private repo to an open one. In the old model, slices of source code from Expo’s private repo (Universe) were automatically synced to several public repos, similar to how the React Native repo is set up. While this model let us open source the Expo client and let contributors send pull requests, we found it created disparity between the way the Expo team developed in the private repo and the way community contributors developed in the open repo. We were less likely to notice and fix issues with the open repo and extra surface area from the disparate workflows added to our maintenance cost. Our new model structurally minimizes this disparity to encourage more community contributions and easily maintain the open-source workflow.
Expoクライアントアプリをオープンにしてここに諸々をコントリビュートしてもらってたけど、ExpoチームはUniverseっていうプライベートリポジトリでやってたので、ちょっとここで相違があったよねと。
いろんなメンテナンスコストとかもあるし、ってことでオープンソースにしますよ的な。
The main Expo repo is now the source of truth of the Expo client and where both the Expo team and community contributors develop. Making the open GitHub repo the source of truth is a systemically healthier model for Expo compared to syncing from a private repo. As part of this evolution, we made the open Expo repo a monorepo—it now contains the Android and iOS runtimes, many Universal Modules, the JS SDK, test suites, the Expo Babel preset, and more — so the implementation of one idea can be in one coherent commit and PR, even if it spans across multiple platforms and programming languages.
We hope the new model encourages developers to contribute to Expo and feel more able even to fork it if they need to.
AndroidやiOSのランタイム、多くのユニバーサルモジュール、JS SDK、テストスイート、Expo Babelプリセットなどを含むリポジトリをモノレポにしたので、複数のプラットフォームやプログラミング言語にまたがっていても、一貫性のあるコミットとPRになるとのこと。
コントリビュートしてもらったりとかフォークしてもらったりとかできるようにしたいなと。
- MITライセンス
Along with moving the Expo client’s source of truth to the open repo, we changed Expo’s various licenses (previously a mix of BSD and MIT) to the MIT License across the board. We chose the MIT License for two reasons: it is popular and relatively well-understood, and both React and React Native now use it. In practice, the BSD and MIT licenses are widely accepted and we expect this change not to significantly affect any developers, but hopefully it is simpler to think about just one license for Expo’s code now.
Expoの色んなライセンスをMITにしましたとのこと。
- JSのセルフホスティング
The JS and some assets for Expo apps are typically hosted by Expo and served through our globally distributed CDN. This is convenient, high-performance, and works well for most developers, but some developers have asked for a way to host their code and assets themselves for various reasons.
We added a new command to the Expo CLI called expo export, which exports a set of files you can host from any static web server your app can access. The Expo docs have a guide to Hosting an App on Your Servers and if you find it interesting to learn about the technical choices behind our work, watch Quin Jung’s talk from React Native EU 2018 (22 minutes).
開発する人の中には色んな理由でJSをセルフホスティングしたいっていう人がいたから、expo-cliでexpo exportっていうコマンドを追加したとのこと。
(ちなみにExpoがv30のときにこれはちょうど発表されてたけど)
詳しいことはhttps://docs.expo.io/versions/latest/distribution/hosting-your-appとかQuin Jung’s talk from React Native EU 2018を見てくれと。
- 自分でスタンドアローンビルドできるように
When Expo developers (using the Expo client) are ready to submit their apps to the App Store and Google Play, they use Expo’s standalone app builders to create IPA and APK files with binaries. Like Expo’s hosting service, the standalone-app builders are convenient and work well for most developers. However, the builder service is shared and sometimes there are wait times or builders go down. We are working on addressing these issues but also wish to give developers more agency when it comes to building standalone apps. To this end, we’ve been working to make the Expo standalone-app builder open source.
The builder, called Turtle CLI (standalone Expo apps are also known as “shell apps” 🐢), is a program you can run on your own computer, server, or CI service. It is written in TypeScript and requires Node.js. For Android builds you’ll also need the JDK and for iOS builds you’ll need Xcode. See the guide on Building Standalone Apps on Your CI Service for how to get and run Turtle CLI.
App StoreとかGoogle Playにアプリを提出する段階でスタンドアローンビルドをするんだけど、待ち時間とかたまにビルドサーバ落ちちゃったりすることもあるわけで。
だからスタンドアロンビルダーをオープンソースにするためにがんばってきたよとのこと。
TypeScriptで書かれてるTurtle CLI（スタンドアロンのExpoアプリは "シェルアプリ"とも呼ばれます）というビルダーを用意したから、PCだったりサーバだったり、CIで実行できるようになったよとのこと。
JDKだったりXcodeが必要だけど。
詳しくはこちらを見てねとのこと。
- カスタムネイティブモジュール
A very popular request for Expo is the ability to write custom native modules. ExpoKit is a native Android and iOS library that lets you still write your app in JS and use Expo APIs while having an Android Studio or Xcode project in which you can write native code. ExpoKit has been a part of Expo for awhile through “detaching” an Expo project but many developers are unaware of it or find it hard to use. From a technical perspective, the pre-built Expo client app from the App Store cannot support custom native modules and ExpoKit or a similar approach is necessary. To address these requests and constraints, we are looking to make ExpoKit a first-class workflow in the future.
With ExpoKit as a first-class workflow, writing custom native modules and native code in general, debugging native and JS code, building binaries on your own CI services, and customizing other parts of your app will be much more streamlined. In addition, we look to make it easier to build custom Expo client apps with custom native modules so you can work on your JS the same way you would with the Expo client app from the App Store while still having your custom native modules.
We believe ExpoKit is the most sustainable solution to broad classes of items in the very long list of requested APIs. The best way for the Expo team to help professionals is to invest in ExpoKit, unblocking developers from writing custom native modules. Additionally, maintaining APIs is expensive for the Expo team, especially as costs accrue in perpetuity. For Expo to succeed, we are looking to invest more in ExpoKit than in new native modules and to create agency and a path forward for skilled professionals to write the native modules they need.
デタッチすると使えるExpoKitっていうのがあって、ExpoのAPIを使いながらもネイティブコードをいじったりできるんだけど、みんな知らなかったりとか使っていなかったりするよね。
それにApp StoreにあるExpoクライアントアプリはカスタムネイティブモジュールサポートできないから、自分でネイティブモジュール作りたかったりしたらExpoKitがいいんじゃないかと。
ということでExpoKitを優先させるようにしていこうかと。
ExpoKitを使うともちろん独自ネイティブモジュールとかも作れるし、さらにカスタムしたExpoクライアントアプリも作れるようになるからいいよとのこと。
Expoチームとして、開発者を支援するためにはExpoKitの開発を進めていくことなんじゃないかととのこと。
■技術とか品質とか厳しさ
When folding origami, the crispness and precision of the early creases shape the final piece. Software is similar and Expo’s level of quality affects the user experience of the final app. Insofar as software is a craft, we are looking to invest more in tasteful, cohesive APIs and increase our attention to detail through our code to our docs.
Insofar as software is engineering, we are raising the level of rigor applied to Expo, starting with the SDK.
Expoの品質がアプリのユーザエクスペリエンスに影響するから、一貫性のあるAPIをもっと作っていきたいと思っているとのこと。
- ハイクオリティなAPI
We are prioritizing quality over quantity and revisiting the existing APIs in the Expo SDK. Our API design values include simplicity and consistency while exposing platform-specific capabilities when needed. In the general case, we want the Expo SDK to behave consistently across platforms and feel consistent across APIs. We are starting with APIs written by the Expo team but the Expo SDK as a whole includes React Native and externally maintained APIs and we need Expo to be consistent and high-quality across the board.
Expo’s API design is comprehensive consideration of edge cases, concurrency guarantees and race conditions, side effects, and other aspects of an API not communicated in a function signature. For example, we are adding explicit error codes to thrown errors that are consistent across platforms, and working to ensure the errors are thrown under the same conditions across platforms.
数よりも品質が大事。
Expoチームが最初に作成したAPIから始まっているけど、SDK内には外部のモジュールを使うようなAPIとかもあるからExpoチームが一貫性と高品質を維持する必要があるよねとのこと。
iOSやAndroid問わず一貫性のあるエラーを投げるようなエラーコードを追加したり、同じ条件でエラーが投げられるようにしたりとか、そういうエッジケースや並行性保証とか競合条件とか副作用とかその他諸々包括的に検討したりとかしてるよ。
- 安定さ
A long-term goal of Expo is to achieve API stability in the vein of the web and continuously release updates with few breaking changes. In practice, because the underlying platforms like Android and iOS annually introduce breaking changes, Expo will have some breaking changes too, but we’d like for those changes to be infrequent and for there to be smooth migration paths.
To start, as part of revisiting the existing Expo APIs, we are designing our APIs with some future-resilience in mind as the underlying platforms change and as we add new platforms to Expo. Eventually we will need other parts of Expo such as the rendering engine and JS–native bridge to be stable, too, but to start we are focusing on APIs authored by Expo.
Expoの長期的な目標として、安定してAPIを大きな変化を持ちつつ継続的にリリースすることとのこと。
AndoidやiOSは毎年激しい変化があるからExpoではいいくつか大きい変更があったりするけど、スムーズになるようにしたいと考えているよ的な。
- 堅実なテスト
Getting code working is often much easier than keeping it working over time, and writing code is often easier and cheaper than maintaining code. To drive down Expo’s maintenance and to preserve a high quality bar, we are adding more tests to the Expo SDK. We have three types of tests:
We are also writing the SDK in TypeScript — another kind of test — to improve the robustness of both the SDK and apps that use it.
- Jest tests: the unit under test is pure JS and we test the integration between JS functions or statements within a single function. These tests mock native modules and I/O and need to run quickly to provide continuous feedback during development.
- End-to-end tests: the unit under test is the entire implementation of an API — including its JS, the native module, the Expo runtime, and the underlying platform — and we test the integration of all of those parts.
- Native tests: the unit under test is pure native code and we test the integration between our native functions and sometimes the underlying platform. We also sometimes mock the underlying platform depending on our intent behind what to include in the unit under test.
Expo SDKには3つテストを入れているよ。
・Jestによるテスト。
テスト対象のユニットは純粋なJSであり、JS関数またはステートメントの統合を単一の関数内でテストします。これらのテストはネイティブのモジュールとI / Oをモックし、開発中に継続的なフィードバックを提供するためにすばやく実行する必要があります。
・エンドツーエンドのテスト
テスト対象ユニットは、JS、ネイティブモジュール、Expoランタイム、および基礎となるプラットフォームを含むAPIの実装全体であり、これらのすべてのコンポーネントの統合をテストします。
・ネイティブテスト
テスト対象のユニットは純粋なネイティブコードであり、ネイティブ関数と場合によっては基礎となるプラットフォームとの統合をテストします。私たちはまた、時にはテスト対象のユニットに含めるべき内容の意図に応じて、基盤となるプラットフォームを模擬します。
さらにより堅牢性を向上させるために、TypeScriptで SDKを書いてるよ。
- React Navigation v3
Nearly all apps have more than one screen and use a navigation library for one of the more complex components in the app. We invested heavily in React Navigation to get it to the 1.0 release and since then have continued to lead the project to 3.0. Some of the reasons we’ve invested so much in React Navigation are because it benefits almost all apps, React Navigation significantly benefits from full-stack optimizations (ex: using native navigation primitives), it provides a consistent API across platforms, and runs on platforms beyond Android and iOS like the web.
- Better graphics performance in the stack navigator: we optimized the card shadow and opacity during transitions and made it possible to toggle both the shadow and opacity on and off. As a bonus, the shadow now properly animates like it does with UINavigationController.
- Integrated react-native-screens: screens build on top of UIViewControllers on iOS and Fragments on Android. Each screen is represented by the same primitives as they would be in a typical native app, rather than a plain view. This will reduce memory usage in most apps, adds support for Reachability on iOS, and paves the way for better integration with other native components because screens now have the same native lifecycle.
- Native gesture handlers: the stack and drawer navigators now use react-native-gesture-handler with the native driver for smoother gestures and better interactions and control over interactions with other gestures.
- Other improvements: new “back” and “slide” types for the drawer navigator, list and scroll views that automatically scroll to the top when tapping an active tab, support for default parameters in route configurations, and many bug fixes.
- The next major release will likely migrate to react-native-reanimated from React Native’s Animated API. This will complete the puzzle of letting us run all transitions entirely on the main thread — from the start of a gesture to when you fling to dismiss a screen or modal.
ExpoがReact Navigationに投資してきた理由としては、完全なスタック最適化（例：ネイティブナビゲーションプリミティブを使用）から大幅に利益を得て、プラットフォーム間で一貫したAPIを提供し、WebやAndroidやiOS以外のプラットフォームでも動作するからとのこと。
React Navigation v3の主な機能
・スタックナビゲーションのパフォーマンス向上：トランジション中にカードのシャドウと不透明度を最適化し、シャドウと不透明の両方をオン/オフに切り替えることができまたり、UINavigationControllerのようにシャドウが正しくアニメーション化されるようになった。
・react-native-screen：iOS上のUIViewControllerとAndroid上のフラグメント上にスクリーンが構築されるようになるので、一般的なネイティブアプリと同じプリミティブで表示されるようになるから、ほとんどのアプリでのメモリ使用量が削減され、iOSでのReachabilityのサポートが追加され、画面のネイティブライフサイクルが同じになるため、他のネイティブコンポーネントとの統合が向上するとのこと。
・ネイティブジェスチャーハンドラー：ネイティブドライバーとネイティブジェスチャーハンドラーを使用するように。
・その他：アクティブなタブをタップすると自動的に上にスクロールするドロワーナビゲーター、リスト、スクロールビューの新しい「バック」と「スライド」タイプ、ルート設定のデフォルトパラメーターのサポートや多くのバグ修正など。
・次のメジャーリリース:React NativeのAnimated APIからreact-native-reanimatedに移行する可能性が高いとのこと。
- AndroidやiOSだけでなく
Android and iOS are two of the most popular platforms in the world and mobile usage continues to rise. However, in addition to native Android and iOS, the web browser on mobile devices is also very popular. Since Expo apps are primarily written in JavaScript and React anyway, we believe that as our APIs and developer tools mature, targeting additional platforms such as the web is viable for Expo. In particular, React Native for Web has shown it’s possible to create websites that load quickly, behave as normal websites, and have as much complexity as Twitter’s mobile site.
As we revisit Expo’s existing APIs, one of our API design criteria is how well the API could extend to many platforms and, in particular, how well it maps to the corresponding web API if one exists. Keeping the web in mind as we revisit component APIs in particular is a key step along the path to defining universal React components (ex: a standard) that all React libraries — whether for web or for native — can use, instead of web libraries using and native libraries using
.
Web support is a long-term future initiative we are considering when revisiting Expo’s APIs, and we will post the first updates on the Expo blog when the time comes. For now, we will continue to focus on Android and iOS and making our existing APIs best-in-class.
iOSとAndroidもそうなんだけど、Webもやっぱり人気あるし、ExpoはJSだからWebもできると考えているとのこと。
そのなかでReact Native for Webは通常のWebサイトとして動作し、Twitterのモバイルサイトみたいな複雑なWebサイトも作成することが可能であることがわかったよねと。
現在は引き続きAndroidとiOSに焦点を絞っていくけど、長期的にwebサポートやっていく予定だよ的な。
■よりよい開発体験
The developer experience is another facet of Expo we have been working on to better support professionals. As with the Expo SDK, we are also raising the quality bar of our developer tools by increasing test coverage and attention to detail in the software the Expo team writes and by making reliable, trusted choices for the software Expo depends on.
開発者の経験は、我々が専門家をより良くサポートするために取り組んできたエキスポのもう一つの側面です。 Expo SDKの場合と同様に、Expoチームが書いたソフトウェアのテストカバレッジと細部への注意を高め、ソフトウェアExpoの信頼性の高い選択をすることで、開発ツールの品質を高めています。
- expo-cli v2
About a month ago we released Expo CLI 2, the replacement for XDE, the exp CLI, and create-react-native-app. Expo CLI includes a terminal CLI and a browser-based GUI, combining the best of both worlds for a superior developer experience while helping the Expo team sustainably maintain one tool and repo. See Ville Immonen’s announcement of Expo CLI 2 for more about the features of Expo CLI.
One significant change not covered in the announcement is that we moved development of Expo CLI from Expo’s private repo to an open one. Like the Expo client repo, the new Expo CLI repo is open-source-first and aligns the Expo team’s workflow with the community contributors’ workflow. The repo contains all of the parts of Expo CLI so that it is easier to write one PR that spans various parts. We hope this will make it much easier to contribute to Expo CLI.
約1ヶ月前に、XDE、EXP CLI、create-react-native-appの代わりとなるExpo CLI 2をリリースしたとのこと。
詳しくはこちらのリリースを見てくれとのこと。
今回ExpoのプライベートレポからExpo CLIの開発をオープンに移行したことがかなり重要な変更の一つだよとのこと。
- TypeScript
Whenever someone from the Expo team talks to developers at JS conferences and asks about the type system they use, if any, the resounding answer is TypeScript. We explored TypeScript by using it for an internal project (our iOS push notification server) and found the type system and inference, tools like VS Code, community knowledge on GitHub and StackOverflow, and the general ecosystem all to be healthy. Additionally, Babel 7 added support for parsing and compiling TypeScript, paving the way for smoother TypeScript integration into the JS preprocessor. After getting feedback on an RFC issue to add first-class support for TypeScript to the Expo SDK, we have decided to move from Flow to TypeScript.
The migration to TypeScript is incremental and underway. A large portion of the Expo SDK is already written in TypeScript but we have several more Universal Modules to migrate. After migrating the SDK, we will be able to explore making it easier to write apps in TypeScript and check types across application code and the Expo SDK. We hope this work will further help Expo developers who are already using TypeScript in other projects or have been interested in trying it.
システムだったり推論だったり、VSCodeだったり、コミュニティだったりgithubとかStackOverflowのコミュニティだったりが健全だったりするし、Babel7でTypeScriptのコンパイルがサポートされるしってことでFlowからTypeScriptへ移行を決定したよ的な。
Expo SDKの大部分はTypeScriptで記述されているよ。
SDKがマイグレートされたあとに試してみてね的な。
- Single-SDK Builds
Previously, standalone-app binaries made with the Expo standalone-app builder service included the native code for the six most recent SDK versions. This allowed developers to change SDK versions when publishing JS updates but we found this rarely to be used in practice. We changed the builders and the Expo client to support single-SDK builds and standalone apps now contain only the SDK version they use when built.
Single-SDK builds are faster, produce smaller binaries, and are isolated from other SDKs. On Android, build times dropped from about 12.5 minutes to 11 minutes (1.1x reduction) and the size of a basic APK dropped from 27MB to 19MB (1.4x reduction). On iOS, build times are the same due to how the builders work and the size of a basic IPA dropped by several hundred megabytes (IPAs contain bitcode and are much larger than the final apps downloaded from the App Store). Additionally, isolating SDK versions means changes to one SDK version are unlikely to affect standalone apps built with other SDK versions. Overall, we hope faster build times and increased isolation will improve the Expo developer experience.
Expoのスタンドアロンビルダーで作られたアプリのバイナリには最新６バージョンまでのSDKが含まれてたけど、これを出し分けして使っていることがほとんどなかったので、単一のSDKビルドだけにすることにしたよ。
より早くビルドできるし小さいバイナリになるよ的な。
- Teams
Many Expo developers building business apps work with teammates on the same app. Expo projects are associated with a single account, so multiple teammates need to share the same account in order to publish JS updates to their app and initiate builds with the Expo standalone-app build service. To facilitate working with teammates, we are working on adding support for team accounts later this year and will have more details and guides to share when the time comes.
チーム的な機能を作って、今年後半にチームアカウントのサポートを追加して行く予定だよ的な。
これでプロジェクトの共有とかができるようになるよ。
■将来的に
- SDK 31, Babel 7, and Modern JSC
The next release of the Expo SDK will be SDK 31. We are upgrading to React Native 0.57.1 and React 16.5.0. Two other notable upgrades are Babel 7 and a much more modern version of JavaScriptCore (JSC) on Android.
Babel 7 brings many changes to its package names, configuration files, and plugin ecosystem and supports TypeScript. SDK 31 will include a new Babel preset for Expo apps that has been upgraded to work with Babel 7.
We also plan to upgrade JSC, the JS virtual machine, on Android. Expo currently uses a version of JSC from four years ago. The new version of JSC is close to iOS 11’s JSC and includes support for nearly all ES2015, ES2016, and ES2017 features such as Symbols, for-of loops, and generators without requiring Babel compilation or runtime libraries. We are optimistic the upgrade will go smoothly but as it is a significant upgrade to one of the most complex parts of Expo, the upgrade may be delayed if issues arise. Hopefully Expo will include modern JSC soon and enable more modern JS features, faster Babel compilations, and smaller JS bundles.
Expo31ではReact Nativeを0.57.1にバージョンアップするよ的な。
さらにBabel7にも対応するようにしてTypeScriptサポートもする的な。
さらにBabelのコンパイルやランタイムライブラリを必要とせずに、Symbol、for-ofループ、ジェネレータなどのほぼすべてのES2015、ES2016、およびES2017機能をサポートするように、JSCのアップグレードも考えているんだけど、うまく行かなかったらちょっとアップグレードが遅くなってしまうかもしれないみたいな。
- SDK 31, Babel 7, and Modern JSC
We have also been working on support for a small number of background APIs, including geolocation. A large part of this project is adding support for background work to Universal Modules. We expect to introduce our first background API later this year.
Geo Locationを含む少数のバックグラウンドAPIに取り組んでいて、今年の後半に最初のバックグラウンドAPIを導入する予定とのこと。
- 64-bit APKs
In August 2019, Google will require 64-bit support for all apps submitted to Google Play. We aim to be ready before this deadline and have taken the beginning steps towards this goal by dropping support for Android versions that don’t support 64-bit builds and upgrading our Android toolchain.
2019年8月からGoogle Playに提出するアプリは64ビットサポートが必要だからそれに備えていくよ的な。
- Paid Services
Expo is a free and open-source platform, which we believe is critical for Expo to succeed. When we talk to developers using Expo or at conferences, though, a common sentiment from professionals working on business apps is they’d feel more confident using Expo if we offered paid plans. We are evaluating ways to offer plans for paid services while keeping Expo’s software free.
As explained earlier, we’ve moved development of the Expo client to the open GitHub repo, and we hope this reaffirms that Expo’s software will stay free and open source. Additionally, supporting self-hosted JS and open sourcing the Turtle CLI builder means developers can serve JS and build app binaries independently from Expo’s services. We believe this is integral to the success of the Expo platform and an important part of why we’re working on Expo; Expo’s software will stay free and open source and developers won’t need to pay money to make apps with Expo.
For businesses interested in a paid plan, we are looking to provide paid services with that are convenient, high-performance, and supported by the Expo team. We are just starting to think about payment models for businesses and will share more when we are closer to offering paid plans.
Expo自体の提供は無料で行いつつ、有料プランを用意することを考えているよ的な。
色々とオープンソースにするし、開発者はExpoでアプリを作るためにお金を払う必要はないよ。
企業向けに有料プランを考えているよとのこと。
- Speed, Quality, Universality, Stability, and Flexibility
Lastly, we’d like to share some of our product values to give a sense of our work in the future. These are five of them:
These are long-term investments and we’ll continue to work hard in order to serve developers and help you build great apps. For professionals using Expo for your businesses, we appreciate your being part of the Expo developer community and helping make Expo a success. And for those working on more playful projects, we hope to share with you some more exciting news soon! 🏰
- Speed: we want to improve performance in several ways, including how long it takes to launch an app, how quickly you can see your changes during development, and how fast it is to create a new project.
- Quality: we’re working so for apps made with Expo to have high-quality user experiences with native views and responsive gestures and to offer coherent, thoughtful, and reliable APIs to developers.
- Universality: Expo and JavaScript are suited to more than native Android and iOS apps and expanding to support other platforms like the web is along the natural path for Expo.
- Stability: with stable APIs and tools, we can reduce the cognitive tax for all Expo developers and make it easier to keep using Expo for the long term, and also improve the stability of apps in production.
- Flexibility: we aim to give skilled professionals more agency to build the features they need by improving support for custom native modules with ExpoKit, making it easier to contribute to the open Expo repo, and other ways we can remove the Expo team from being a bottleneck.
・スピード：アプリの起動にかかる時間、開発中の変更の表示の速さ、新しいプロジェクトの作成の速さなど、いくつかの方法でパフォーマンスを改善したい
・品質：Expoで作成されたアプリでは、高品質のユーザーエクスペリエンスを持ち、開発者に一貫した思慮深く信頼できるAPIを提供するよう努めたい。
・普遍性：ExpoとJavaScriptは、ネイティブのAndroidやiOSアプリ以上のものに適しており、Webなどの他のプラットフォームをサポートするために拡張したい。
・安定性：安定したAPIとツールを使用することで、すべてのExpo開発者のカロリーを削減し、Expoを長期間使用し続けることを容易にし、生産におけるアプリの安定性を向上させることができる。
・柔軟性：ExpoKitでカスタムネイティブモジュールのサポートを改善し、Expoのリポジトリに貢献しやすくしたりとかしたいと考えている。
長く時間がかかるかもしれないけど、素晴らしいアプリを開発するために引き続きがんばっていくよ的な。
ってな感じ。
大きく変わったところとしては、パブリックなリポジトリにするとか、スタンドアローンビルドを自分でできるようにしたよとか、TypeScriptサポートするとかチーム機能とかなんか色々。
かなり大雑把に訳してしまったっていうのもあるけど、とりあえずExpoは日々色々と改善してるみたいでよい的なみたいな。
0 件のコメント:
コメントを投稿