I’ll be honest, if you don’t own or regularly use a Mac or an iPhone, the odds that you are going to make compelling software for either of those platforms is effectively zero.
The web and app stores are littered with the corpses of failed, poorly-ported iOS and macOS utilities written by developers who didn’t fully understand that those systems have their own design language, cultural norms, and feature sets. They chew through battery, perform poorly, confuse users, look like shit, and feel completely alien.
Should that totally stop you from porting some useful tool? Maybe not. But the chance that it will see any sort of use outside of an extremely niche set of users is slim and it’s worth accepting that upfront if you’re going to spend your time and effort on it.
While I agree that the app will likely feel off, that doesn't mean it won't work, depending on what it does.
I have an iPhone, and even though the number of non-default apps I use is quite small, I get the feeling that every other app is just a web view wrapper or whatever that just doesn't care about iOS standards. The examples that come to mind are: Uber, Teams and Philips Hue. The latter is a laggy mess for some reason, that behaves the same on an iphone 14 pro as on a 7. Teams also is a shitshow, but who does that actually surprise?
I hear this refrain a lot, but the reasons I've gotten for native apps vs webapps were not very compelling to me. I'd be interested in a detailed comparison of some real examples of native and web (or react native-like or webview wrapper) apps and the practical differences (excluding obvious ones like hardware access.)
Oh, I'm not saying it can't be done, and if it could, I'd be happy.
It of course depends on what somebody deems "compelling". What comes to mind is, mostly, behavior that feels off when any sort of animation is involved. Mostly the "rubber-band effect" when scrolling past the first / last element of a list as well as the scrolling action itself. This is surprising to me, since I'd expect ios' web view, being safari, to behave the right way. But I wouldn't be surprised for these sites to hijack scrolling, as many sites do on the desktop.
Then there are the expected gestures which don't always work. Take the uber app and the "back" gesture: they sometimes do, but sometimes they don't, even when there's a back arrow present. And when they do, they feel off. The current image doesn't begin sliding smoothly from the edge, it waits a bit and then it "jumps" to some distance. Also, in Uber, for some reason, just scrolling up and down for example in my past trips stutters. Yeah, I know it loads those as it goes, but even after the list is populated, it keeps stuttering. After a while, if I stay on that page, it seems to be smooth, though.
Then there's the typography, which is often weird.
Now I guess you could always have those issues even with full-on native apps, especially the last point. And I doubt it's impossible to go out of your way to mess up scrolling, as some devs do that for the browser.
But mostly, native apps behave a certain way which some people may come to expect from their devices. To me, it's compelling enough that, given the choice, I'll pick the "native" app over the weird one. I also don't care the least bit about "brand experience" or whatever it's called, so not having your weird font is actually a feature for me. I also only have an iphone, so don't care about the app behaving the same on multiple platforms (though I can see the value in that for support).
Also, I don't care that the app is actually native, what I care about is its behavior. So, if an app is able to have the same behaviors while actually being a bunch of JS inside a web view, I don't really have a problem with that.
Huh, surprised by this because the Hue app runs great for me, don’t think I’ve ever seen it lag as a daily user for a couple years. Honestly kind of blown away but how well it (and the Hue platform as a whole) works coming from a company that I don’t usually associate with tech.
Goes to show that experience doesn’t always generalize, and I’m curious what’s different in our cases to cause that (since I’m also using on a iPhone 14 Pro).
I'm generally very happy with how my Hue setup works, but for some reason the Hue app sometimes lags on the simpler screens, like the settings tab and configuring the remotes' buttons. The Home tab where you set the scenes / brightness and such usually works fine.
> sometimes lags on the simpler screens, like the settings tab and configuring the remotes' buttons
That's because there is no cloud storage or place to store those settings other than the devices (or the bridge) themselves.
You are not waiting on the app. You are waiting on a request and response to the device over Zigbee to save the settings, which is not an instant action.
Maybe they could just close the screen and finish the work in the background, but I like knowing it completed successfully.
Say there exists a single-page, single-view form-based web utility (e.g. a tax calculator for some niche.) Does the job. Efficient UX. Solves a need rather than a want, so it doesn't need to be pretty.
Only problem is that it's hosted on some old website, meaning:
1. you have to bookmark it (and the bookmark probably doesn't come with a nice icon, and you could lose track of it in the future because it's not part of some "store download history" list);
2. you can't access the calculator when offline;
3. the site's server could go down tomorrow, and then "your" calculator wouldn't be there any more.
AFAICT, from the perspective of a mobile user, the only thing that could possibly be improved about this experience, would be the very fact of it being hosted on the web. As long as it's made into a client-local installable package, registered in an app store with a name and icon, all the above problems are solved. And you get those key advantages, just by saving the webpage .html to a file, wrapping it in Cordova or whatever, and submitting that as your app.
(You also get almost these advantages using Progressive Web Apps that use offline capabilities — all except for discoverability and esp. re-discoverability through a unified app-store UX. If the app stores allowed the submission of PWAs, such that they appeared in the store listings and download history right alongside native apps, I think a lot of use-cases for Cordova et al would be moot.)
In practice, poorly ported web apps often fail in various ways. Things like content covered by the keyboard, or the layout breaking when you rotate the device, or random other stuff that results from a lack of testing. It's what happens when developers don't use the device they're targeting.
The funny thing is that "no porting" is often a better experience than "half-assed porting."
Which is to say, if all you do is wrap some late-90s/early-2000s never-been-mobile-optimized .html in Cordova — then when you open the app, you just get a regular webview, that shows you the same old webpage. It probably starts out too small, because it was laid out for PCs; but you can still pinch-to-zoom, rotate to change the viewport, or whatever else you do to regular websites on a mobile web browser. By default, all those web-supporting browser features are there, in every webview.
Or, to put that another way: by default, Cordova's webview is just showing a webpage using the same logic a browser does; and by default, browsers show webpages as webpages, rather than as pseudo-apps.
It's only when someone has started down the mobile optimization journey, and starts embedding meta viewport user-scalable=no et al, that you start to see these wrapped apps suffering from all the UX jank you're talking about.
If you've got an HTML4 webpage, you don't need to test it specifically wrapped in Cordova, to know what it will look like when Cordova attempts to render that HTML4 webpage. It'll look like it looks — and work like it works — when a web browser on the same OS loads that webpage. And you can test that just by loading the same webpage in one of those browsers (or through one of the many SaaS sites that do so by proxy.) Or even forego testing entirely, if you know that people were already successfully using that HTML4 webpage from the browsers on their phones. A "raw" port won't change anything about that experience.
If you do decide to start down the road of trying to mobile-optimize the webpage, though — then yeah, you're gonna see a lot of jank, and will want some heavyweight local simulators to debug that jank.
Applications (not games) developed and published for macOS and iOS by lone developers with little to no experience on those platforms is overwhelmingly unlikely to be used by enough people to reasonably justify its development.
There are exceptions to this for specific niche use-cases. There are situations where this has not ended up being true. There are times where one might want to write such an application to scratch their own itches with no real need or desire to gain a critical mass of users. None of these invalidates my general point.
"Compelling" software in the one you are compelled to use, for example you go to a techy-utopia-restaurant and want to order order your food, but then are compelled to install their app because their system is automated /s
Games are the main appstore revenue driver, and I don't think that game ports have much to do with iOs standards. It isn't like Fortnite or Genshin Impact on iPhone is significantly different than on Android.
Genshin Impact is (potentially) an interesting case - the iOS version has supported game controllers for almost 3 years now, but there's been no hint of support coming for Android. There's definitely some suspicion in the Genshin community that Apple has an understanding or agreement with Hoyoverse to keep iOS the premier mobile platform.
Would it be legal under US law for Apple to make payments to Genshin to keep iOS as the premier mobile platform? Related: Similar question if Sony wanted to guarantee Final Fantasy was always better on their platforms.
True, but there is also a business opportunity for dramatically simplifying game deployment, not only web apps.
Unity has tools that can partially help with that but their execution also sucks. You still need some half-working script downloaded from Github or some random site to deploy to Apple/Google if you don't want the hassle of using the default tools.
It's the same for consoles. It's an ungodly pain in the ass even with Unity. Godot makes some of its money by porting to consoles, for example. But I don't know if there's any money there for a scalable solution.
It means video games. And even amongst the most predatory mobile games, not all of them use gambling-adjacent "gacha" mechanics, plenty just have mountains of microtransactions.
Apple cracked down on traditional gaming on iOS, and as an unforseen side effect, yes, "mobile gaming" means suggestive gambling apps that are eating the world.
I agree in principle, however IMO there is room for much simpler apps that don't necessarily follow the UI conventions of the platform and still provide a magical experience. The keyword here being "simple".
The app of my Bank (Commerzbank) looks the same in both platforms (despite being native, last time I asked), and IMO provides a much better experience than lots of native Apple or Google tools. And IMO a better UI/UX too. Same with Monobank from Ukraine, astonishing app that doesn't really care about the platform and gets things done in IMO a better way than native-inspired apps.
I would prefer for most apps to move into the Commerzbank direction than in the... I don't know, Pixelmator? Which is 100% native but still feels very unintuitive sometimes ("Save as" for example) despite being my daily pic editor for 15 years...
Isnt this what style guides and, like, profiling are for? Which we should be using anyway right?
I don't understand this fundamentally epistemological point. I thought in some part my skill as a programmer is being able make things not necessarily for me. Or at least, as a (maybe kind of niche) frontend dev, I don't think I would have ever gotten a job without some semblance of that skill.
I feel like if I relied on my own experience instead of agreed upon standards I would be much more a designer who makes bad code than a coder who maybe just needs a little design/ux direction.
That is absolutely a useful resource, maybe even a necessary one, but I personally doubt it’s sufficient.
It’d be like trying to learn a foreign language entirely off something like Duolingo. At some point the only way for you to communicate like a native is going to be to embed yourself in the language and culture, otherwise you’ll never quite express things like a native.
Steve jobs once said that great software has 1:50 ratio. Meaning for every 50 poorly designed apps there is 1 very well designed app. He said that in the 90s, I think it’s still true to this day.
Yes, ports where each platform is treated as a checkbox to be ticked are practically always poor, with little to no testing. The dev dumps a cross-compiled binary they may not even be capable of running themselves and that’s the end of it. Sometimes they happen to work passably but that’s not a given.
The web and app stores are littered with the corpses of failed, poorly-ported iOS and macOS utilities written by developers who didn’t fully understand that those systems have their own design language, cultural norms, and feature sets. They chew through battery, perform poorly, confuse users, look like shit, and feel completely alien.
Should that totally stop you from porting some useful tool? Maybe not. But the chance that it will see any sort of use outside of an extremely niche set of users is slim and it’s worth accepting that upfront if you’re going to spend your time and effort on it.