Hacker News Reader

Comment by TekMol | Hacker News Reader

I have a web application with a lot of users. My users are happy to use the web. But because of better monetization options, I sometimes dabble with the idea to build a native mobile app.

Some years ago, I tried to build an Android app. It required an insane amount of tooling. Hundreds and hundreds of megabytes of stuff. GUI applications you have to use etc. I didn't even try to build an iOS app because that probably means you have to own a mac.

Is this still the same?

Or are there some linux command line tools these days I can use to convert a web app into an app that I can put on the Android/iOS app stores?

View on HN

There are things like Cordova that make it a bit easier, but yes you need hundreds of MBs of stuff to compile and test. Debugging was a bit of a nightmare, though.

It is also possible to deploy to Apple with things like Github Actions without personally owning a Mac (and it can publish to Google too, naturally), but then testing is not trivial.

I know 90% of HN will disagree but there is a market opportunity here to make this better.

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.

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.

No, but it doesn’t sound like GP was talking about games. Yes, games are a completely different animal.

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.

I assume "games" here means gambling? Or something that is not legally gambling, but effectively is.

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.

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.

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?

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.

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.

> Teams also is a shitshow

I heard it works wonderful if you use Microsoft Surface Duo devices

This is very funny/sad because Uber has one of the biggest iOS teams in the world.

What is "compelling software"?

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 theory I agree with you.

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.

> What is "compelling software"?

"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

I'll be more descriptive:

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.

  confuse users, look like shit, and feel completely alien.

Developers eyes glaze over when you start talking about users.

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.

ps: Is this not a sufficient resource?

https://developer.apple.com/design/human-interface-guideline...

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.

Sounds like Sturgeon's law.

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.

I know you can't port a web app to it easily. But Expo, wrapper around React Native, does do a great job at handling that. It also comes with a build in ci/cd and over the air bug fixes (alternative to codepush)

I've set up a custom flow with Fastlane with React Native. Works pretty well, but Major Version, OS and architecture update are a huge pain.

Interesting. I haven't worked with React Native or Expo, but that sounds exactly like what I was suggesting.

It's YC funded: https://www.ycombinator.com/companies/expo

> Debugging was a bit of a nightmare

Debug in Android Studio, connect phone on USB, enable USB debugging, hit play button

Debug in Xcode, connect iphone (wireless), hit play button

Exactly. You need Android Studio or Xcode. Fucking pain in the ass.

You don't need them, but they do make things easier for a lot of people. With Android, at least, you can do plenty from the command line if that's your jam.

My problem with them is not so much that they are GUI tools. It's more that they are bloated, low-quality and a bit unpredictable. IMO and IME, of course. They do get the job done, and people can get used to them if they use daily. But if using them is not your daily job (and Stockholm Syndrome hasn't set in), they make for a terrible developer experience. They take a lot of time to setup and there's often various problems with versioning, for example. All IMO and IME, of course.

I used to work in a Cordova/PhoneGap/Ionic/[whatever the name is today] app I had to make those bi-monthly excursions to the codebase that would always take a couple days because of Android Studio or Xcode. Setting the tooling in a new computer or teaching this to a new developer would require a lot of fiddling with version for half a day or more until it worked properly.

Sure, if you work on it everyday it doesn't suck, but working with multiple apps or working with different things was always a terrible experience.

I only used Android Studio when it was in beta so can't say much about that. But XCode is honestly quite good, not perfect by any means, but especially with Swift and SwiftUI it has some really good features (to wit: live previews).

Provisioning and testing purchases is always a mess, but that's mostly because the code world meets politics there.

Again, they're fine for development as a daily driver. For casual use (occasional maintenance/debugging, publishing), not so much.

But that sounds like a function of the complexity involved with mobile development and those tools being a do it everything tool for their development (with Android especially, all the different os versions you can target, the different form factors). What would you like for casual use?

The problem is not the form factors or the depth of the tooling. I'm not even going into different form factors.

The major issue here is how the default experience is unpredictable and messy, and restoring/kickstarting a proper development environment takes hours/days instead of minutes, and it breaks quite often if you're

What I would like is predictable builds and isolation. Packaged, versioned and rollback-able development dependencies, like we have with backend/frontend web tools.

Things like Cordova's CLI and Unity's Build Server help halfway with this, but there's more work to be done even with those tools.

What I'm suggesting is that some company could step up and handles this, plus things like CIs, deployment bureaucracy, instant demos of web apps on phones, etc, like someone mentioned above that Expo does for React Native.

for a small window of time, there was an alternative... https://creolabs.com/ but this is gone now.

Google has a CLI tool for producing an APK bundle: https://github.com/GoogleChromeLabs/bubblewrap

Tutorial here: https://developers.google.com/codelabs/pwa-in-play

You can build on the command line with gradle.

I did end up installing Android Studio for the sdk and virtual machine installation, but I'd assume it could be done on the command line as well.

I've downloaded just the command-line tools before and used 'sdkmanager' to list and download sdk versions and virtual machines, so it is definitely doable without Android Studio, although it isn't obvious (or at least it wasn't to me).

I don't understand why this was getting downvoted? The parent commenter is right. You can build on the command line with gradle. It will still download hundreds of megabytes worth of dependencies (the Android SDK etc). But at least you don't need any GUI tools.

It's an SDK for an entire OS, plus the emulator (basically the whole OS in a VM), developer tools and more. It's not much different in size than the SDKs for macOS or Windows and it's much more cohesive.

I have done this, but for some reason Android SDK has to be weird, so you have to download the SDK seperately and then create a properties file in to root of the project with the path to the Android SDK. Everyone then also has to have their own version of this file, since the path is likely different. You also have to make sure that everyone downloads the same version of the SDK. (also the path to the SDK cannot have any spaces)

Why can it not be like other Gradle dependencies, where Gradle will just download the files automatically?

The irony is that most people who think they want an app would not see the difference between that and a shortcut to your webpage.

just porting a basic chrome web extension, like 2 js files to safari requires something like 10 GB of Xcode downloads and various other crap.

i'm not doing that.

Why not if I may ask? Vim only user? Its possible to build ios and android apps with your own build tools. Its a lot true.

i believe apple intentionally makes it difficult. especially in the case of safari web apps because of their app store monopolies.

so i just dont want to support their web browser or their platform in general. as a personal choice.

i build some tools for work colleagues using web extensions and i refused to port it to safari. someone else can take that task if they wish.

I tried to build an Android app. It required an insane amount of tooling. Hundreds and hundreds of megabytes of stuff. GUI applications you have to use etc.

FPGA developers snicker under their breath, but if you look closely you can see the tears welling up in their eyes...

Google has Bubblwrap, which will take any PWA and create an Android wrapper for you: https://developers.google.com/codelabs/pwa-in-play#0

There are tools like that for iOS too, but you absolutely have to have a Mac.

I've had success with react native for deploying web type apps onto both ios and android. Expo really flattens the learning curve, it's something to grow out of for sure. I look at it like having an app vs wanting to have an app.

What do you use for front end for your web app? If you use React or Vue or something that does client-side rendering, you can often turn your app into a PWA fairly trivially by just adding a manifest. That is IMHO definitely the way to go as long as you don't need to use native functionality/APIs.

PWAs are still a little tougher on Apple since Apple holds the reins to their platform very tightly and doesn't want apps getting to users without going through "curation," so if iOS is an important market for you and your users will find you through the app store (rather than looking for you in the app store after finding you elsewhere), then a PWA may not be the best choice.

If you use server-side rendering, then it will of course be more work, but I'd still probably go the PWA route and write it in React or Vue. You already know JS so there's much less learning, and it's the most "write once run anywhere" that there is. You'll likely have to buy a mac though, although there are services you can "rent" one for building/signing/submitting to Apple.

React Native can be a good option as well, especially if you need to call native APIs or must be in the Apple store (Google Play Store can take you as a PWA). Most of your code can be js/ts so less learning curve, and you can generate a submittable app package that can go in the Apple store (and of course Google).

If you need to make extensive use of native APIs though, then a real native app may be better, though of course you will need a separate one for ios and android, and there's a lot of learning to do. And you'll definitely have to buy a mac.

tldr: a PWA is (probably) the way to go

> But because of better monetization options, I sometimes dabble with the idea to build a native mobile app.

Likely not in this case.

Not if you use Flutter

Does anyone use that in production for large B2C applications?

Google pay is written in Flutter

https://flutter.dev/showcase has many high profile examples

Yeah this answers the question pretty much

The French railway ticket website, sncf-connect.com is in Flutter.

Largest e-commerce service in France.

Flutter is pretty nice, but I have a really hard time trusting Google to continue supporting it.

One of the Flutter primary devs just left Google and is still working on Flutter at his new gig.

That's a good sign that it's getting some momentum outside fo Google.

(I agree with you, though. Sadly, the Flutter management team seems to be where Google sends shitty managers for punishment.)

Is it https://shorebird.dev?

It’s still the same. You can rent a Mac in the cloud for iOS development though.

Try to create a app like behavior in javascript and use a webview in android and ios to wrap your app. We do it like that. You will still have some native parts like push notifications, ads, social logins etc. But your ui render is web. Just make sure you have an app like experience. Doable these days.

>It required an insane amount of tooling.

The all the extra tooling makes it easier to make Android apps. Nothing is stopping you from downloading the Java JDK and Android SDK and running javac, d8, aapt2, zipalign, and apksigner yourself.

> Nothing is stopping you from downloading the Java JDK and Android SDK and running javac, d8, aapt2, zipalign, and apksigner yourself.

That is the tooling that OP is talking about.

It sounded to me that they thought they had to use Android Studio as they were complaining about a GUI.

Perhaps a progressive web app will work for you

Look into PWA.

Yes.

So the size of the tooling was about the same size as the your web app pushes on every user?

The horror.

Reply on news.ycombinator.com