5 ms·
This may have been historically true, but our internal data shows us that starting early 2017, people in tier 1 countries were equally likely to pay and have co
by Pharaoh2 9y ago
This may have been historically true, but our internal data shows us that starting early 2017, people in tier 1 countries were equally likely to pay and have comparable LTV on both platforms.
And if you also going to launch in EU/Australia/Canada, you will have a nearly 50-50 split of ios and android users on a platform neutral app.
So the classical logic of implementing on iOS first doesn't really apply anymore. Now its more, implement first on the platform you are comfortable with but don't forget about the other platform because there is a equal amount of money to be made there...
PS: Data excludes low end iOS and android devices. (< SE, old iPads/iPods, old and cheap android devices). These devices have extremely low conversion on both platforms anyway.
- sebleon 9y agoThe logic still applies. 1. Start with platform you're most comfortable with. 2. Iterate on product until you have a winning formula 3. Replicate on 2nd platform to double revenues Building is a lot easier than identifying what to build, better to speedily experiment on one platform.
- jjeaff 9y agoIn my opinion the new logic is build in React Native (unless your app fits in the 10% of use cases that won't work well with RN), then deploy to both at once. We have had excellent results.
- ewjordan 9y agoReact Native is great for apps, and if it's a game, just use Unity. They're building up their internal CI infrastructure and it works better every month. Tbh, I'm not sure how many use cases don't fit either React Native or Unity, I'd practically never choose to do an app another way these days.
- rimliu 9y agoI'd say RN won't work well in 99% cases.
- dnate 9y agoI wish everyone downvoting you would at least state their problem with your post
- pjmlp 9y agoI rather use native UI code + C++ for business logic, use Qt or Xamarin than even bother with React Native.
- sebleon 9y agoMy take is that RN is great for demo apps or simple UIs, but I would not choose it for a production app where performance matters (ie. using camera, audio, custom controls, platform-specific SDKs, multi-threading, etc). You're definitely going to do heavy lifting in native code, and a hybrid app quickly becomes a mess. Dealing with multiple environments and super slow build times in Xcode will seriously slow down development cycles. IMO RN is no exception to the Simple vs Easy trade-off [1] Not to mention using RN gives FB a legal blank check from your company [2] [1] http://chrisfrost.com/wp-content/uploads/SimpleVsEasy-478x512.png http://chrisfrost.com/wp-content/uploads/SimpleVsEasy-478x51... [2] https://medium.com/@raulk/if-youre-a-startup-you-should-not-use-react-reflecting-on-the-bsd-patents-license-b049d4a67dd2 https://medium.com/@raulk/if-youre-a-startup-you-should-not-...
- jjeaff 9y agoThat article is out of date. As of September 2017, FB has re-licensed React under the MIT open source license and dropped the patent stuff. I don't think you contradicted anything I said. I would say special camera apps, multi-threading etc. are not needed that often. As for slower build times, that is the beauty of RN. Building is not needed most of the time just an initial build and a rebuild every time some of the base configurations change or you are creating code outside of RN.
- sebleon 9y ago> fb dropped patent stuff Ah, thanks for the update, glad they did that > are not needed that often Right - statistically most apps are probably throwaway code for hackathons or demos. However, I'd venture to say that >50% of serious apps will end up needing performance boosts from native code. > Building is not needed most of the time You need to rebuild every time you make a change in native code (obj-c or swift). Hot reloading is cool for JS changes, but bloat from RN becomes a nightmare when debugging obj-c or swift issues.
- jsnell 9y agoHave you thought about writing up your findings? I haven't seen any report break out the data like that before.
- Pharaoh2 9y agoEdit: s/comparable LTV/comparable ROI(~= LTV-CPI) You will have equal ROI, with the LTV being slightly lower on android but so too will the acquisition cost... overall profit being the same.
- sidlls 9y agoThat's interesting. I am admittedly using my recollection of data I saw a year or so back. Has the fraction of iOS users who pay gone down or the fraction of Android payers gone up?
- Pharaoh2 9y agoConversion on android has gone up, along with users on high-end android devices. At the same time CPI on iOS has gone up. Speculation: iOS users may be running into app fatigue and just don't want to install new apps anymore.
- nodamage 9y agoIs this referring to free apps, paid apps, or both? I've had a paid app on both stores for about six years now and in my experience the iOS version makes about 10x the Android version every year. Many other developers have reported a similar discrepancy.
- Pharaoh2 9y agoSorry should have clarified, I am taking about freemium apps , both subscriptions and IAPs. Don't have data on paid apps. Also I am talking about app that are well monetized and advertised so you have an level comparison instead of chart positions giving and sustaining a significant lead on one platform just by some fluke.