And just like that, by dropping Android support, Buddybuild goes from viable solution to total non-starter. Does any serious mobile app development these days really go all-in on one platform?
Fwiw: We also wish there was a way to publish test/linting results (you can make it an artifact, but it won't load assets, so you're stuck zipping and downloading or publishing to your own managed Web server)
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.
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.
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.
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-478x51...
[2] https://medium.com/@raulk/if-youre-a-startup-you-should-not-...
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.
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.
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.
Speculation: iOS users may be running into app fatigue and just don't want to install new apps anymore.
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.
Solutions that support both are thus more popular and better idea - but Apple obviously is using all kinds of tactics to discourage development for competing platform. Even buying companies and shutting down their Android (TestFlight is another example).
Immediately killing all Android related functionality is to discourage that development though.
Why would Apple invest resources into making developer tools for other platforms? What's the real upside if Buddybuild continued as is and they tried to scale it up? Hundreds of millions in revenue per year? That's a drop in the bucket. Buddybuild's value is strategic, not because it was going to make a financial difference to Apple.
Couldn't they fork the project, keep everything but the name for themselves and set a single guy on maintenance; wouldn't that enhance their own developer tools just as much?
I don't recall many iOS and iOS only apps. There was just generally and Android time-tax that Android users had to wait through.
Its pretty low key lucrative too:
- iOS development is crowded, Android devs are more scarce and there are too many unrelated skillset paths to build a native android app.
- The APIs are already developed by the time you get there.
- The designs have already happened, for the most part. Its no longer a fact finding mission and instead a pure implementation mission.
- You make more money and have to deal with less company-wide fires in the process.
- Nobody bothers you. You get to be on autopilot.
- And its also pretty pointless. Most company's android apps are just a checkbox, store presence to show they haven't neglected it. Nobody is going to actually download it.
It was fun for a while, I got my funds up.
There is a ceiling you can make doing mobile dev, and companies don't make a return from pursuing it
React Native solves the needs of most companies' apps on both platforms, they'll figure it out all pretty quickly at the same time
Noone remembers your app exists after a few months, why did you expect anyone to give a damn about your product after two whole years?!
During that two year delay we made the iOS version a quality product instead of having our attention divided by another platform that delivers less than 10% of the userbase. It was the right move.
Your attitude is very common among iOS developers and it's the main reason why you only have 10% of userbase on Android - companies that actually understand their audience have no issues reaching wide users and profits on both platforms.
If you deliver a subpar submarketed product on App store you will fail. If you deliver a subpar submarketed product on Play Store you'll fail as well. It seems you did the second thing.