Can anyone explain to me why iOS apps are so huge? For example the SSH client I use weights over 190MB, while the most popular Windows one is a whooping 2MB (while having more features). What went wrong here?
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
As of April 30, All Apps Submitted to App Store Must Use iOS 13 SDK or Later
- Thread starter MacRumors
- Start date
- Sort by reaction score
I have the simulator for the SE and I don't remember creating it so I guess it is part of the defaults.
I'm ok with Apple enforcing the use of 13 SDK, if you don't want to support dark mode there is a simple key in the plist to set so you can force the app to be light and don't have to deal with it.
UIWebViews are going to be deprecated, you can still use them for existing apps but not for new app, and that is more serious than just adopting 13. WKWebViews have been there for a long time, but had some limitation at the beginning so people like me avoided them for as long as possible.
I'm not sure about the iPad, I think sooner or later they'll force us to have apps that support being resized. Some of my apps only work fullscreen, I'm lucky as I distribute the majority of them outside of them as they are for enterprise environment, but this is going to be a real problem. Some apps do work only on portrait or landscape, once they'll force us to adopt to all size classes people will need to completely rewrite their UI.
That's a very good point. Honestly I wonder what iOS 13 APIs will be absolutely necessary for use because, AFAIK (and I do no poking under the hood or development myself on iOS), there have been no obvious changes to core function that would make using newer APIs a requirement unless you wanted to take advantage of new features (I.E. apps like MacTracker probably won't need to implement any new APIs unless the developer wants to make it a dark mode-capable App, which I could see causing issues with the visibility of some of the computer pictures, so that probably won't happen)
If I had to guess they mean that the app must be able to scale to the screen size of any supported device.
Well, first off they're not directly comparable as iOS apps are compiled for the ARM architecture and Windows executables are compiled for the x86 (or x86_64) architecture. This means that they don't contain the same instructions and so the size would logically be different. Also, with Windows I can presume there are fewer things like graphics APIs that have to be utilized whereas with iOS there are likely certain APIs that must be used to make the app. Probably most of that weight is UI code if I had to guess, which is understandable due to the nature of a touchscreen device.
Are you talking about the space you can see in Documents and Data or the weight of the app when you download it from the store?
It is not easy to give you an answer, some of my apps are huge because I need to include hundreds of images and video but if I keep things simple the app skeleton is about 5MB. If you include third party libraries you have additional space required.
In general I think developers underestimate the problem. When I stared writing iOS apps I had to support the original iPad with only 256MB or RAM and I had all kind of constraints, nowadays we have amazing CPUs and even storage is not a problem as most devices start with 64GB.
Apple did a good job with app thinning, but even devs have to be good citizens.
You're comparing Oranges to Lemons.
It's way too common for malware apps to reach the officially sanctioned Google Play store. You cannot say the same thing about Apple.
Jailbreaking has nothing to do with this topic: Hundreds of million iOS users (like myself) get by just fine without needing Emulators. Just because you seem to think they're needed doesn't make then so.
Have also noticed that iOS ipa tend to be significantly larger than equivalent Android apk. Both ipa and apk are just zip files so you can open and look at the content to compare. For example. FlightRadar24 ipa is 186MB while FlightRadar24 apk is 45MB.
That’s why there is choice, Android for more freedom but can be a bit messy or IOS which is more restrictive but more polished and balanced.
I don’t think Apple cares about emulators that 0.0001% of people care about. That’s nerd stuff.
I mean, I'm a nerd but I don't care about getting emulators on my phone because I see my phone as a communications device and little more. Not even all nerds feel the need for emulators on their phones.
I’m a nerd myself, I know not all do, but generally average joes don’t care about that stuff.
Both Objective-C and Swift have ways to use newer APIs selectively without breaking the code for older OS versions. Similarly, dark mode is (from a technical standpoint) easy to implement if you limit the interface to (derivatives of) Apple’s UIKit or Cocoa components; in that case, it is enough to just build the app against the 10.14/iOS 13 SDK and UIKit/Cocoa does the rest automatically.
Branching code with selected newer API calls can make the codebase ‘ugly’ and complicated though, which is why there is a certain cost to maintaining support for older OS versions while adding support for new APIs.
I think that apps like WhatsApp do not get enough credit for their backwards compatibility. Even though they release new features slowly, they do aim for an implementation of many APIs and generally maintain the look and feel of a native app on every OS version they support.
The car analogy is a good one. If you have a ten year old car and someone how wants to supply ten year old parts and an engineer who want to fit those parts, he doesn't have to go to the manufacturer to allow him to open the bonnet and gain access to the engine, only to be told we are not going to let you have access to the engine you have to but a new car. "NO apps can be submitted " not just those that want to make use of the new feature "No APPs". Thank you for your car analogy, it fits perfectly.