zlacker

Almost certainly has to do with how the app is built. Most thoughtfully built native SDK (UIKit, etc) apps clock in well under the 100MB mark, often under half or a quarter that.

Bloat like that is usually due to unnecessarily convoluted tech stacks pulling in a list of dependencies that goes out to Mars and back, or for globally targeted apps sometimes it’s translations for everything in the app for hundreds of different languages.

>>cosmic+(OP)
Yeah but the native SDK sucks and isn't cross-platform, I don't blame anyone for not using it

>>frollo+S
UIKit is fine, good even, SwiftUI isn’t fully baked yet, Android Framework definitely sucks, and Jetpack Compose is decent but needs work. Both platforms have at least one SDK that’s good to use, and personally I’d take them over fighting the extra layer of issues something like RN adds on top of the native issues that devs will encounter regardless of the SDK used.

Cross platform frameworks really aren’t the magic wand they’re sold as.

>>cosmic+e1
Cross-platform is very much not a magic wand, but it's still often easier than building the same thing in two different native SDKs, and I can see why people do it.

Disagree about UIKit, mainly cause of Autolayout, unless it's gotten reworked in the past 8 years. When I started using RN, I had zero web experience, and still it was way quicker to set up a basic UI than in the UIKit stuff I'd been doing for years. And for all that setup, Autolayout doesn't even seem to future-proof your stuff that well. An abandoned ObjC iPhone app I wrote in high school using C-style macros for layout worked perfectly fine on the newer screen sizes that broke most other apps.

I thought maybe I was stupid, but the other iPhone devs I worked with constantly had problems with Autolayout. Maybe a real expert iPhone dev won't, but it shouldn't take that.

>>frollo+B1
The thing about UIKit is that you really need to forget about the drag and drop UI editor (XIBs and storyboards). They make everything including autolayout much more painful than they need to be.

Pure code UIKit using autolayout’s anchors API is quite serviceable, and if you follow recommendations (use safe area and keyboard constraints! They exist for a reason) reasonably futureproof. The iOS apps I’ve worked on have needed very little change year to year for quite some time at this point.

>>cosmic+(OP)
"clock in well under the 100MB mark"

But this is still incredibly ridiculously comically gross. The fact that we can afford it these days is an irrelevant seperate thing. These numbers are just unjustifiable for what most apps actually do.

>>cosmic+d2
That's true, though some will tell you the opposite. But even then, the pure code autolayout seemed a lot harder to use than HTML/CSS. The fact that so many people got it that wrong says something. Like yeah a desktop website might break on mobile, but I'm talking about a mobile screen just getting slightly longer or something.

>>Brian_+r2
Yeah, especially if I can make a desktop app under 10 MB with the same functionality and features (obviously non-Electron).

>>Brian_+r2
I mean, it scales with complexity. Naturally, well-made native SDK apps bumping up against 100MB are more likely to be highly functional, while simple apps are very small.

For a couple examples pulled from my TestFlight list, there’s a social media site reader app that’s 7.6MB and a text editor that’s 697KB. Those sizes aren’t the least bit unreasonable.

>>cosmic+S3
What are these you are listing?

>>cosmic+(OP)
Whats the business case to invest in building these well and as small as possible?

Heck, if you are a world business and the app isn't your core value prop, whats your case for investing anything more than the bare minimum in creating your app?