[HN Gopher] I shaved 187MB off United Airlines' 439MB iOS app
___________________________________________________________________
I shaved 187MB off United Airlines' 439MB iOS app
Author : trevor-e
Score : 488 points
Date : 2022-02-23 16:04 UTC (6 hours ago)
(HTM) web link (telkins.dev)
(TXT) w3m dump (telkins.dev)
| azinman2 wrote:
| What is the Android size? Google play store tells me it varies
| with device, and I don't have any android devices.
| haxiel wrote:
| 76 MiB for my Android device.
| mwcampbell wrote:
| I think the most effective way to fix this systemic problem would
| be for app stores to start charging developers for app size, both
| for storage and outbound transfer. And for desktop apps
| downloaded from websites, all hosting providers and CDNs should
| start charging for egress like the big cloud providers do, in
| acknowledgement of the fact that bandwidth isn't free. Yes, I
| recently migrated some of my company's infrastructure off of AWS,
| in part so we wouldn't have to pay for egress. I now believe the
| world would be better off if we didn't have that option.
| tantalor wrote:
| If app sizes trend down, it might serve the users well, but it
| would depress iPhone sales as fewer users would need to upgrade
| storage.
|
| Which one do you think Apple cares more about?
| srvmshr wrote:
| If App sizes go down, its a win for Apple as well:
|
| 1. Faster update downloaded to devices compared to before &
| to Google/Android. That's a big PR win.
|
| 2. Most badly behaving apps have tons of unnecessary process
| & their binaries. Also storage is taken up by UI assets. If
| these are streamlined & reusable, the footprint goes down.
| That means less RAM can still do fine.
| tantalor wrote:
| > big PR win
|
| But it wouldn't move the sales needle. Nobody is going to
| switch from Android because they were waiting for smaller
| download sizes.
|
| > less RAM can still do fine
|
| That's bad for Apple because it discourages upgrading.
| srvmshr wrote:
| Regarding PR, it adds ammo to their oft repeated claim of
| "best mobile OS" (Not that I fully agree)
|
| Size and RAM (and indirectly a modest battery life gain)
| will be a win for whoever uses, regardless of our
| personal views on this matter. When developers throw in
| big frameworks mindlessly, they assume best case use.
| Minimalist and efficient coding will actually win across
| the board whichever way you look.
|
| As far as Apple devices go, they are getting support way
| longer than Android flagships. Apple is devious possibly
| in many ways, but they don't get to win by 'planned
| obsolescence'. Much rather the opposite: as new
| generations of devices come in with newer hardware, they
| don't have to crazily support a lot of firmware and
| instruction sets. Only the ones which satisfies the newer
| frameworks. If they did, they will turn out as another
| Intel (which famously supported a lot of opcodes all the
| way back to 386). Their fanbase has some (valid) strength
| based on a lot of older generation devices still getting
| OS upgrades which they might normally wouldn't have.
| swalls wrote:
| MS did this with the Xbox 360. Developers just stopped updating
| their games.
| blah_humbug wrote:
| We _need_ bloat, and more than that, we need _necessary_ things
| to be bloated. Otherwise, how will we keep the tech sales
| treadmill moving?
|
| Conversely, it may be that only bloated tech will survive, as
| bloat drives sales, and sales means survival.
| jmbwell wrote:
| United Airlines has been posting jobs for internal application
| development for a while... --including at upper management
| levels.-- Just saying.
| kazinator wrote:
| Only 250 more to go.
| kloch wrote:
| so _that_ is why they say before every single flight "Make sure
| you download the United app before takeoff as you will not be
| able to download it in the air".
| nhoughto wrote:
| 187MB of symbols seems like alot! Kind of funny that this bloat
| could be reduced by X% just by having a shorter path in the CI
| pipeline and not even stripping, also surprising that xcode
| doesn't strip swift symbols by default for a release build? Some
| low hanging fruit right there
| alberth wrote:
| You know what also have huge app sizes, it's various iOS email
| app. Fastmail is the only email/calendar app with a reasonable
| size (just 20MB) [0].
|
| - Gmail (397MB) [1]
|
| - Outlook (328MB) [2]
|
| - Hey (69MB) [3]
|
| - Protonmail (128MB) [4]
|
| [0] https://apps.apple.com/us/app/fastmail-email-
| calendar/id9313...
|
| [1] https://apps.apple.com/us/app/gmail-email-by-
| google/id422689...
|
| [2] https://apps.apple.com/us/app/microsoft-outlook/id951937596
|
| [3] https://apps.apple.com/us/app/hey-email/id1506603805
|
| [4] https://apps.apple.com/us/app/protonmail-encrypted-
| email/id9...
| petters wrote:
| It's ridiculous. The complete size of Mario 64 with all assets
| is 6MB.
| anthk wrote:
| And the whole 9front weights less than those apps.
|
| When I was a Windows user, a video player install of more
| than 80MB would be slightly bloated.
|
| Today my OpenBSD install uses less than 3GB and it has far
| more stuff than a phone install.
|
| Golang binaries are like 5-15x the size of a dinamically
| linked C binary, yes, but at least they provide everything
| and run everywhere.
| dj_mc_merlin wrote:
| C and Go are at a very similar level of portability.
| Statically link your C binary with musl and it will run
| everywhere the Go binary (built on the same system) would.
| Neither Go nor C will run outside their architecture or OS,
| but both can cross compile.
|
| Go makes both processes more user friendly. Statically
| linking with musl is simple in C (musl-gcc), but cross
| compiling is a bit of a pain the ass to set up (building
| your toolchain from the ground up). Not too bad, and if
| you're messing with building portable executable this kind
| of knowledge is assumed.
| kuschku wrote:
| I've built a full android IRC client in 4.1MiB. Most UI
| elements are custom, no web view for anything, lots of
| custom libraries etc. That's > 200kLOC. I can't fathom what
| you'd have to do to get to 100x that.
| antihero wrote:
| Can't imagine an IRC client has many high resolution
| assets.
| kuschku wrote:
| Why should it? Android supports vector assets, I ship
| everything as vector drawables. 98 vector assets, full
| text of 11 licenses and translations for 9 languages are
| > 90% of the 4.1MiB
|
| That said, what assets does an email client need beyond
| what I use as well?
| NikolaNovak wrote:
| Do they have comparable functionality; in particular, are they
| all actual genuine native apps with offline capability; vs a
| glorified hyperlink to their web interface?
| kelnos wrote:
| They don't; the Fastmail app is just a web view. It's
| completely non-functional when there's no internet
| connection. Really glad to find this out now, and not when
| I'm in an airport or something somewhere with no internet
| connection and really need to look at an email related to my
| travel arrangements.
| wodenokoto wrote:
| > Fastmail is the only email/calendar app with a reasonable
| size (just 20MB)
|
| It's because it doesn't contain anything. You can't even see
| any UI, let alone emails without being connected to the
| internet.
| jacobr wrote:
| I just went into airplane mode to try, and the app works fine
| on iOS. It shows a message about not being able to fetch new
| emails.
| pletnes wrote:
| I just did the same, and it says that I need to be
| connected to see my emails. <<Are you in airplane mode?>>
| wodenokoto wrote:
| Did you remember to turn off wifi and close the app (not
| just go back to the main screen and back into the app)
|
| https://support.apple.com/en-us/HT201330
| winrid wrote:
| Adding offline access would indeed be nice, but that wouldn't
| even add 2mb of code. I have entire native mobile games with
| multiplayer under 3mb.
|
| EDIT: just realized the app is a web view. Sigh
| nindalf wrote:
| That was literally what the previous comment was trying to
| tell you.
| squeaky-clean wrote:
| Web view apps can still work offline if they're designed
| for it.
| kroltan wrote:
| Yes, but the 3mb is just the wrapper, I bet if you delete
| the hundred-ish megabytes of cache, it won't work offline
| anymore :)
| [deleted]
| samhw wrote:
| But that's entirely fair: of course caching data uses up
| storage. But it's my choice - I can pay for what I use.
| The crucial part is that I don't need to download an app
| which is hundreds of megabytes large _just in order to
| hypothetically support_ caching.
|
| No one can tell me that our species can write 1K ZX Chess
| (https://en.wikipedia.org/wiki/1K_ZX_Chess) - an entire
| chess game with intelligent opponents which only takes up
| 672 _bytes_ - and yet we can 't write an email client
| which isn't a million times that size.
| ComradePhil wrote:
| It's often the high-res assets (images, videos, sounds,
| animations etc.) which take up most of the space, not the
| code itself.
|
| When it comes to the code, the reason that they are
| bigger is how apps are distributed and have isolated
| runtimes. There are several commonly used sdks and
| libraries but because of how mobile app distribution
| works, these common libraries have to be bundled with
| each app and are not installed as a reusable library
| (like you can do with Linux, for example).
| lupire wrote:
| That game was famous for how bad it was, except that it
| miraculously fit in a tiny package.
| kroltan wrote:
| I agree if cached data was actually proportional to
| usage.
|
| But a lot of these webview kind of apps just download the
| whole thing anyways, so it's literally just a matter of
| if the bytes are classified under "application size" or
| "cache" by the OS.
|
| (Precisely so they have the whole thing available for
| when you need to use it offline)
| vmception wrote:
| I've been judged by prospective employers based on reported
| app size being seen as correlated to complexity. VC backed
| startup I worked at for 18 months with a 12 megabyte app
| size due to efficient design choices? Must be a joke
|
| So now I just add a 150 megabyte dummy file at everyone
| else's expense
|
| I'm sure there is a lot of that going on given how long
| some job roles were open, I have to imagine that every
| mobile developer on the market may have passed through and
| made the same conclusion!
| uoaei wrote:
| Well it may not be correlated to complexity but it
| certainly is correlated to end user satisfaction. If
| their device prompts a "device cleanup" operation and
| your app is near the top of the list that doesn't do much
| good for retention.
|
| Not to mention the billions of devices in the world which
| are running old OS versions with scant memory capacity.
| lupire wrote:
| > billions of devices in the world which are running old
| OS versions with scant memory capacity.
|
| are not the rich or loose-walleted people that app
| sellers and advertisers care about.
| vbezhenar wrote:
| Release lite version without that file.
| rixed wrote:
| > I've been judged by prospective employers based on
| reported app size being seen as correlated to complexity.
|
| This judges the prospective employer more than it judges
| the candidate, doesn't it?
|
| This is actually nothing new. Back when I was at uni some
| students claimed to do the same, adding code that served
| no purpose to inflate the resulting program executable
| size.
|
| And if my memory serves me well, at this time when
| windows was still young and software was swapped around
| on floppies, software sizes started to skyrocket and I've
| heard then that the secret reason for this lack of care
| was that size was the easiest way to impress users and
| the tech press (all while making piracy more
| inconvenient).
| vmception wrote:
| > This judges the prospective employer more than it
| judges the candidate, doesn't it?
|
| Easy to say, rhetorically suggesting that its revealing a
| toxic mangement environment, but no, not really. My
| experience has been overwhelmingly positive with great
| teammates and great managers, and a hiring decision maker
| that was otherwise completely hands off of what I was
| doing for the rest of the project. A hiring decision
| maker that probably left within 3 - 6 months of me
| joining, or who was randomly called to do an interview
| last minute and had arbitrary evaluation metrics. Maybe
| _that_ is what you mean, but it had nothing to do with
| the day to day experience, once on board I found every
| place to be very similar with the mobile team pretty much
| on autopilot, which is the desired experience. Even
| quicker paths to leadership roles and higher
| compensation.
|
| They all have interesting-enough projects at the time, or
| fulfilled some other interest of mine, or money without
| being a bad environment. Interview gaffs really don't
| carry as much weight as people think, it requires a
| special kind of privilege to think it matters that not
| all of us have or had.
| klodolph wrote:
| On the other hand, when your app is actually functional
| at 12 MB, you'll find users from more parts of the world
| using it.
| emteycz wrote:
| You can geofence a Lite version
| vmception wrote:
| Yes when I ever make an app for my own project
|
| But for most employers they just need presence, almost
| nobody was breaking even on apps they just needed the
| presence on the app stores. Big waste of money for most,
| and for most projects I was pitched
| meibo wrote:
| To add some context, Gmail also includes a lot of the core
| workspace apps(chat, meetings, etc) if you do have a workspace
| account, which most users will likely never see.
|
| All of that isn't needed on regular accounts, I guess, but it's
| probably easier for them to ship it as one app because people
| might get confused/are able to switch between their workspace
| and regular accounts in the app. Gmail is also supposed to be
| the "hub" to workspace on their new Desktop UI.
| alberth wrote:
| Isn't chat, meeting, etc all separate apps from Google (and
| not included in the core Gmail app).
|
| https://apps.apple.com/us/app/google-chat/id1163852619
|
| https://apps.apple.com/us/app/google-meet/id1013231476
| meibo wrote:
| These are "standalone" versions, but they are also all
| built into Gmail if you have an account that has access to
| them.
|
| They do exactly the same thing on Android - Gmail has it
| all by default, if you want them separate, you can get them
| from the play store.
| munk-a wrote:
| Drive, at least, is both a separate app and integrated - if
| you try and open a docx file in GMail it will invoke some
| of the drive code to render it.
| squeaky-clean wrote:
| They've shoved all that functionality into the Gmail app. I
| actually uninstalled Gmail because it became the default
| app to open Google Meet video calls, even with Google Meet
| installed. I don't need my email app asking me for video
| and microphone permissions...
| acchow wrote:
| What happens if you uninstall all the Google apps and
| then reinstall them in a different order? (Google Meet
| first)
| lxgr wrote:
| This specific case is more of an artifact of iOS's
| inability to handle multiple apps declaring the same URI
| launch scheme cleanly than a problem with Gmail on iOS,
| in my opinion.
|
| Picking a default handler for a given scheme seems like a
| problem best solved at the OS level, and I don't even
| know how an app developer would be able to fix that.
| lupire wrote:
| > I don't need my email app asking me for video and
| microphone permissions...
|
| You do if it is also your video chat app. If not, decline
| permissions.
| tempnow987 wrote:
| They also have an authentication option they are building in
| (ie, sign in with the app to web properties). I've noticed a
| bunch of stuff seems to be migrating into gmail.
|
| My own view is they burnt people out install allo, hangouts
| etc, and people DO install gmail / have gmail accounts -> so
| they are going to try to leverage that for distribution a bit
| more.
| jamra wrote:
| That sounds like a reasonable point of view. But it could
| be that they are just trying to up sale their other
| services and can more easily do so if it's bundled in an
| already used app.
| lupire wrote:
| That's what parent said.
| lxgr wrote:
| Gmail being a "hub app" makes some sense, actually (unless
| you're not using Chat or Meet, of course).
|
| What annoys me much more than that is that Docs, Sheets and
| Presentations all are multi-hundred megabyte standalone apps,
| of which I'm guessing 80%-90% of the code is identical/pulled
| in from some non-shared library.
| acchow wrote:
| I wonder when iOS will allow for dynamically linked shared
| libraries from the same Developer account.
| fredoralive wrote:
| I suspect it's a hard issue for the App Store model.
|
| You don't want a situation where someone updates App A,
| it updates a lib, then App B breaks because it hasn't
| been checked against the new library. I know _you_ are a
| good developer who would check that, use major / minor
| library versions correctly etc. but there are lots of
| developers on the App Store. Or the fun case of updating
| App A, it updates a lib and then magical new features
| appear in App B that Apple doesn't like.
|
| You'd probably have to use some sort of strict library
| versioning system where every app version is tied to a
| very specific library version. Are developers in general
| going to be disciplined enough to actually keep their
| apps all in sync on a specific version so older versions
| of the libraries can be removed? Or does this just mean
| every app from a developer will end up having its own
| slightly different revision of the lib tied to them? If
| it's the latter its probably not worth Apple's time
| adding all the complexity to manage the libraries to the
| App Store system.
| hirako2000 wrote:
| And introduce a well known problem, not so well solved by
| OS makers and their developers outside Linux (somewhat).
| Windows and its developer community kept failing, it has
| improved in the recent years though, Apple decided long
| ago they would rather sacrifice space to guarantee a
| package will execute as intended. (even so, sometimes
| still fails as native libraries do change and aren't
| packaged). And upsell larger storage as highly profitable
| addons.
| stefan_ wrote:
| Does it make sense? Every time I click a link in GMail it
| opens some weirdly broken browser imitation instead of
| opening it in my chosen browser. This is supremely weird.
| lxgr wrote:
| That's also a common iOS app annoyance, but a different
| one than either of these I'd argue.
| lupire wrote:
| Android is worse -- it opens in a real Chrome webview,
| but in a broken frame that displaces the original app.
| Melatonic wrote:
| Yea I am definitely one of those people who hates all that
| crap in my email app - I have workspace at work and normal
| gmail for home use and even on desktop it just annoys me. I
| like having a big fat separate chat window for all the
| people I'm annoying
| jshchnz wrote:
| Used Emerge Tools size analysis to analyze the binaries, here's
| some quick findings to answer some questions:
|
| [0] Fastmail: smallest of the apps but still could have room
| for improvement, could save almost 20% of the app size by
| optimizing their audio files. 71% of the app is the binary.
| Check out the X-ray here: https://emergeassets.s3.us-
| west-1.amazonaws.com/Screen+Shot+...
|
| [1] Gmail: looks like most of their bloat is coming from
| localizations. Only 60% of the app is binary, while 24% is
| localization files. Check out the X-ray here:
| https://emergeassets.s3.us-west-1.amazonaws.com/Screen+Shot+...
|
| [2] Outlook: could be stripping binary symbols to save
| significant space. 65% of the app is binary, while 14% is
| localizations. Check out the X-ray here:
| https://emergeassets.s3.us-west-1.amazonaws.com/Screen+Shot+...
|
| [3] Hey: could save about 15% of the size of the app just by
| removing duplicates and optimizing their images. 45% of the app
| is binary, 27% of the app is assets, this is definitely higher
| than it should be. Check out the X-ray here:
| https://emergeassets.s3.us-west-1.amazonaws.com/Screen+Shot+...
|
| [4] Protonmail: could save almost 30% just from image
| optimization and duplicate removal. 58% of the app is binary,
| 14% is assets, and 7% is localizations. Check out the X-ray
| here: https://emergeassets.s3.us-
| west-1.amazonaws.com/Screen+Shot+...
|
| Unfortunately this is a very common problem as many teams don't
| have any monitoring in place. Here's another example of a
| popular email app Spark, automated insights show over 100 MB of
| easy savings:
| https://www.emergetools.com/app/example/spark?buildContent=i...
|
| For pretty much every app here, Emerge's insights found at
| least 20% in easy size reduction. FYI, in the X-ray
| visualizations, red indicates duplicates and we can breakdown
| apps even further using builds with dSYMS!
| newman314 wrote:
| Thanks! This is very interesting to see all the low hanging
| fruit. Out of curiosity, could you run Emerge on a few other
| common apps: the United app as well as Yelp, Twitter and
| TikTok?
|
| Those seem to be the biggest consumer of storage for me.
| sond813 wrote:
| I tried it out with Yelp and Twitter, both had a lot of
| bloat due to not stripping binaries. You can see this in
| the large "String Table" in both screenshots.
|
| Yelp also has a large exports section for the main app
| binary, that's usually a sign of a problem because the main
| binary doesn't need to export any symbols, only frameworks
| do that.
|
| Twitter has a handful of 4MB images, much bigger than
| images you'd expect in an app. I took a look at a few of
| these and they are just gradient background images that
| could have been drawn with something like core graphics to
| completely eliminate the need for an image.
|
| Twitter: https://emergeassets.s3.us-
| west-1.amazonaws.com/Screen+Shot+...
|
| Yelp: https://emergeassets.s3.us-
| west-1.amazonaws.com/Screen+Shot+...
| PascLeRasc wrote:
| For some reason it's really funny to see how much room
| Fastmail's notification sound takes up. Your analysis for
| Spark also has a send sound bundled but it's one of the stock
| Apple ones (Blow). Is there a reason why they have to include
| their own copy instead of relying on a system sound file?
| sond813 wrote:
| We've seen this happen with system fonts as well, apps
| sometimes bundle the San Francisco font with an app instead
| of relying on a system font. There may be some reasons to
| include the font or sound file, such as if it changes in
| different versions of the OS. Of course that would make the
| app inconsistent with the rest of the OS, which may not be
| the best behavior. We discuss some other tradeoffs with
| bundling these system resources on our blog post which
| covers the Spark app: https://www.emergetools.com/blog/post
| s/7AppsThatCouldSaveYou...
| alberth wrote:
| Thanks for sharing. TIL about Emerge. Super interesting.
| PascLeRasc wrote:
| The new Shortwave is only 22Mb! It's also just a web view like
| Fastmail though.
| brnt wrote:
| So... how does a webview, which is a call to a system api,
| take 22MB?
| marcellus23 wrote:
| Fastmail is also mostly a wrapper around web views (but then
| again, so is Hey)
| a13n wrote:
| You should check out Missive, it's even less at only 19.3MB.
| Also an incredible product
| https://apps.apple.com/us/app/missive-email-chat-tasks/id123...
| Bilal_io wrote:
| I checked on Android. Gmail's app size is 113mb, while Tutanota
| is 4.58mb
|
| I wonder why the Gmail app is almost 4x the size on iOS.
| mojuba wrote:
| Probably because on Android it already has most of the
| frameworks (including tracking ones) it needs pre-installed
| with the OS.
| alberth wrote:
| Interesting, I just found this (dated) article.
|
| https://mobilityarena.com/ios-apps-are-larger-than-
| android-a...
|
| It supports your claim that iOS app sizes are 3-10x bigger
| than Android.
|
| I wonder why. The article makes some guesses but still, the
| magnitude difference is significant.
|
| Even Fastmail, which has the smallest iOS email app, is still
| 2x bigger on iOS (20MB) vs Android (10MB).
|
| https://play.google.com/store/apps/details?id=com.fastmail.a.
| ..
| ComradePhil wrote:
| The sizes mean different things in different platforms.
| Google reports the download size, Apple reports the size
| that the app will consume on your device. Both have their
| uses but you shouldn't compare the two.
| [deleted]
| nicksaroha wrote:
| Outlook makes sense because they use React Native in their app.
| If you look at their License sections they are using a ton of
| libraries which is common.
| pianoben wrote:
| React Native is one cause. Another is that they ship a
| tremendous amount of cross-platform c++ Office code, which is
| not small.
| kitsunesoba wrote:
| I haven't analyzed their binaries or anything like that, but
| I'd wager that a significant chunk of the heft of the Gmail and
| Outlook iOS apps are Google/Microsoft's custom UI frameworks.
| throwawaylinux wrote:
| That's terrible.
| [deleted]
| achandlerwhite wrote:
| I've heard that some of them include their own network stack so
| that only they can track your data. I think that was in
| reference to Facebook's app originally but I wouldn't be
| surprised.
| junon wrote:
| That would require raw socket access which would surprise me
| if it was allowed, as it's usually a superuser privilege on
| UNIX for good reason.
| cout wrote:
| I'm not sure whether to find it amusing or concerning that 20MB
| now qualifies as a reasonable size for an email client. My
| first PC that ran Linux had only 8MB of RAM and an 850MB disk,
| and it felt like a lot at the time.
| godshatter wrote:
| I was thinking the same thing. What happened? I started
| programming on machines with 16K of memory or less. It was a
| point of pride for developers to make programs that did the
| most with less, like the whole demoscene movement. It's like
| the contest changed from who can make the leanest code to who
| can get away with packaging the most bloat in one app without
| causing the device to break. We went from shaving off
| individual machine instructions to packaging entire browsers
| with super-simple apps.
| ricardobayes wrote:
| I had a financial app bloat up to 800MB+ due to some botched
| incremental updates. I firmly believe in 2022 those who care
| about bundle sizes are in minority. I personally come from an
| embedded dev world so I got accustomed to fighting for bytes as
| I learned to program. Nowadays if I suggest something to save
| space, I usually get a blank stare.
| jeffbee wrote:
| _This_ is the kind of thing the App Store review process should
| be flagging.
| bluedino wrote:
| They'll introduce it as a feature at the next WWDC. The best
| App Store yet!
| bitwize wrote:
| You joke, but really, if anyone can change the economics of
| development to dissuade app cruft, _only_ Apple can. Apple
| routinely achieves with a wave of the hand things that years
| or decades of concerted effort from industry professionals
| couldn 't do. Things like remove and deprecate DRM from
| music.
|
| This is Apple's industry, we're just allowed to play in it.
| Scoundreller wrote:
| Why? Bloat drives sales and upgrades.
| memco wrote:
| So does optimization and efficiency. Apple can add this in at
| some point and say they reduced App sizes by X% across the
| entire App Store at WWDC and get lots of oohs and aahs.
| ChrisMarshallNY wrote:
| Agreed, but I'm wondering if they will.
|
| I'm a real "dependency skeptic." Doesn't make me too many
| friends, hereabouts.
|
| I'm also not a fan of running Web code on the phone, like a lot
| of PWAs and hybrid systems. Again, doesn't make me popular, in
| this crowd.
|
| If the main app runs afoul of stripping symbols, then the App
| Store inspection can flag it. If, however, it's a dependency,
| then I could see them tossing out boatloads of apps, simply
| because they include piggy frameworks. There's really no
| automated way for Apple to realize the framework is really just
| the developer's aggregated code, or from another source, over
| which the developer has no control.
|
| What _really_ needs to happen, is that the developer has their
| own inspection regimen, before submitting something that could
| cause brand damage, to the App Store.
|
| Again, suggesting stuff like this, is tantamount to heresy, in
| today's "Move fast and break things" tech world.
| boredumb wrote:
| I recently bought a 100$ android waiting for my phone to be
| repaired and the size of modern apps on older hardware render
| them completely unusable. It's a shame that the amount of bloat
| creeping into everything in the name of "developer productivity".
| Do we have to wait until we hit some limitation in storage size
| before we decide that it's simply dog shit software? Samsungs
| "notes" application is almost 100mb in order for me to keep track
| of a few kb of grocery lists and restaurant suggestions.
| hparadiz wrote:
| Here I am agonizing over adding an extra 20 MB of assets to an
| app that is only 22 MB to support a new design.
| jb1991 wrote:
| I don't understand why this actually happened, why were the names
| not stripped? That seems like a terrible thing not just for size
| but also for insights into the developer's process (in this
| case). Shouldn't Xcode be doing this automatically? The author
| even points out that Swift doesn't need them, so why are they
| there?
| mech4bg wrote:
| >It's becoming somewhat of a popular trend in the airline
| industry to cut costs by having the passenger bring the hardware,
| and as an added bonus they get to force their way into your
| coveted list of installed apps.
|
| TBH I see this as a positive - less weight on the plane, less
| fuel consumed, less waste when these screens are junked, etc. I
| personally always take a ton of videos with me and just watch my
| own stuff, I would never trust that the in-flight stuff is
| working (although I admit I overprepare and it's still important
| to provide this). And when you're flying - having the app
| installed is a net positive, it has maps of the airports (with
| great directions, which is super helpful when you're making a
| connection), can manage your ticket, etc - the videos are a
| bonus.
| lentil_soup wrote:
| > less weight on the plane, less fuel consumed
|
| For a plane that's negligible.
|
| Tbh, I don't want to sit on a 12hr flight watching a phone
| screen. I have to hold it on my hand, have nowhere to put it
| while eating, I have to plug it in to a charger as well (and
| it's never guaranteed there'll be a plug) + what the OP said
| about having to download more stuff to my phone I don't want or
| I might not have space for.
| mech4bg wrote:
| FWIW I've noticed on a lot of airlines removing the screens
| have phone holders in their place and always have a USB
| charger.
|
| It's a moderate weight saving, there are some details in this
| article: https://www.fastcompany.com/3034196/airlines-are-
| tossing-sea...
| Spivakov wrote:
| "most bloated apps are within the 100-200MB range, not 400MB."
|
| WeChat enters the chat...
| markstos wrote:
| At a job interview, I pointed out the company could cut their
| bandwidth in half if they enabled gzip compression on their web
| server.
|
| I got the job.
| rob74 wrote:
| "App review failed: your app contains >30% cruft. Please remove
| cruft and re-submit"
| dzhiurgis wrote:
| How is that not done by Apple's servers automatically?
| hnburnsy wrote:
| Apple\Google should charge for over-sized apps, just like some
| airlines charge for over-weight bags.
| azalemeth wrote:
| I once flew United and, like the author, didn't realise this
| until I was on the plane for a ten hour flight. Downloaded the
| app for Android. I opened it. I was immediately ip-blocked for
| having a rooted phone, which was then kicked off the network and
| couldn't get an IP address. United cabin crew then started trying
| to sell me an iPad loan for the duration. I read a book and vowed
| never to fly with them again.
| agar wrote:
| This was probably a response to a hack that occurred in 2014.
| It wouldn't surprise me if it was mandated by the FAA or
| similar regulatory body.
|
| https://www.cnn.com/2015/05/17/us/fbi-hacker-flight-computer...
|
| > During FBI interviews in February and March, the document
| says, Roberts told investigators he hacked into in-flight
| entertainment systems aboard aircraft. He claimed to have done
| so 15 to 20 times from 2011 to 2014.
|
| > He also said, according to the document, that once he had
| hacked into the systems and then overwrote code, enabling him
| to issue a "CLB," or climb, command.
|
| > "He stated that he thereby caused one of the airplane engines
| to climb resulting in a lateral or sideways movement of the
| plane during one of these flights," the document says.
| tyingq wrote:
| I doubt it. You can bring a "rooted" linux laptop onto the
| plane and it works, so banning rooted phones from inflight
| WiFi would be a little silly.
|
| I am interested in the linked story, but it's very odd that a
| passenger wifi network would be cross-connected with flight
| controls.
|
| That the network on a non-wifi seatback entertainment system
| could be is a little more believable, but I'm still curious
| how it wouldn't have resulted in an extended grounding of all
| aircraft of that type if it were true. There was no
| grounding, or order to modify that system following his
| twitter posts and subsequent arrest.
|
| Edit: If you search around for what happened after the
| incident described above, it seems pretty clear he did not
| send any commands to flight systems. He seems knowledgeable
| about them, but seems to perhaps have been caught out talking
| about a theoretical scenario as if it happened. He wasn't
| charged, and as mentioned, no actions were taken to change
| anything. I suspect the networks are properly isolated.
| xmprt wrote:
| I hate when apps lock out rooted Android phones for "security
| purposes" when it's so simple to get around it by just
| directly accessing the API or spoofing. It's even dumber when
| the app/website can be accessed through a laptop which is
| much more permissive than a rooted phone. I've never heard a
| reason for why companies do this.
| mdoms wrote:
| Not defending the blocking of rooted devices, but I think it's
| excellent that airlines are relying on people bringing their
| own hardware. I think you'd struggle to find a single person in
| an airport who isn't carrying a screen with them today, so
| seat-back screens feel very redundant to me.
| rekoil wrote:
| As a person who carries a 5.4" iPhone 12 mini, please keep
| seat-back screens. I wouldn't mind if they were just HDMI-
| devices I can extend my devices screen to though, that would
| be amazing!
| tonywastaken wrote:
| They had a similar check for jailbroken iPhones. The last time
| I flew with them they seem to have fixed it.
| digisign wrote:
| Fixed to block or not block?
| tyingq wrote:
| I'm surprised there would be that kind of integration between
| the United app and their on-board WiFi, which appears to be run
| by Panasonic.
|
| It sounds like you're saying the United app noticed your phone
| was rooted, and somehow it notified the on-board WiFi to block
| your ip/mac? Or am I not reading this right?
| varenc wrote:
| That's also how I read it, which astounds me. Would be
| technically impressive if it worked like that. And extra
| vindictive since even if they don't allow rooted devices to
| play DRM'd video, there's no good reason why they should also
| be prevented from buying in-flight internet.
|
| (one solution if that's really how it works: rotate your mac
| address, reconnect, and then never open up the United app
| again so it can't squeal on you.)
| tyingq wrote:
| You could also wreak some havoc by banning the macs of
| other devices on the plane that want to use the WiFi...so
| I'm pretty skeptical this cross-service integration is
| really there.
| iamcreasy wrote:
| > I was immediately ip-blocked for having a rooted phone
|
| What is wrong with using their app on a rooted phone?
| stevep98 wrote:
| Likely a DRM requirement so you can't pirate their movies
| tyingq wrote:
| Not saying it's the right decision, but probably because they
| don't want the liability if a rooted device allows some 3rd
| party app to hack theirs. Airlines can be somewhat like a
| small bank in this respect, as being logged in gives you
| access to things like accumulated loyalty points, not-flown-
| tickets that can be exchanged/refunded, past flight credit
| from earlier refunds that were eligible for credit but not a
| cash refund, etc.
|
| Also, they typically store more personal info than, say, an
| e-commerce application because some of it is needed for
| travel. Things like date of birth, known traveler numbers,
| names/dob/etc of family members, passport numbers, etc.
| _fat_santa wrote:
| Unrelated to their inflight entertainment, United pulled this
| stunt on me the other day.
|
| - Flight at 11AM, boarding at 10:20.
|
| - Show up at 10:25, boarding doors are closed.
|
| - "Didn't boarding start 5 minutes ago"
|
| - "Yeah we close the doors once 95% of people show up, sorry,
| you should show up when boarding starts"
|
| - "Yeah but didn't boarding start 5 minutes ago, how was I to
| know"
|
| - "You should have known, sorry"
| sb057 wrote:
| >Yeah we close the doors once 95% of people show up
|
| So they are essentially scamming 5% of passengers out of
| their tickets?
| vel0city wrote:
| I mean, you're _supposed_ to be at the gate when boarding
| starts. For all practical purposes if you miss boarding you
| 've missed your flight even if the plane hasn't left the
| ground due to safety rules about letting passengers go
| after the door is considered closed.
|
| There's a bit of a checklist of things that need to be
| completed after the door gets closed and the gate pulls
| away. They're often incentivized to try and speed things
| up, so if there's nobody at the gate anymore to board they
| might assume those passengers decided not to go on the
| flight. Especially with people now checking into flights
| the day before, the airline may not even know if the
| passenger is even at the airport and would realistically
| show up to the gate anytime soon as checking in means
| pretty much nothing these days.
|
| They're not scamming anyone. Your ticket said you were
| supposed to be at the gate to board at a certain time. You
| weren't there, so you missed the flight.
| xmprt wrote:
| I get that rule. But why does the door close at boarding
| time and not at the flight time or some predetermined
| time like 10 minutes before flight time or when boarding
| completes, whichever is later.
| vel0city wrote:
| The door closes when it seems like there's no more
| passengers so they can hurry up and start working on the
| checklist. They do this so they can potentially get going
| sooner in case there are delays elsewhere in the many
| steps that goes from passenger boarding to plane in the
| air. Theoretically they could be more rigid about having
| a time for the door closing, but that could potentially
| mean there are more actual delays as now they no longer
| have a chance to gain some time in their schedule to make
| up for potential delays elsewhere.
|
| If the door closed at flight time then the plane wouldn't
| be leaving at flight time, it would be leaving at flight
| time + the time it takes to go from boarding to getting
| in the air. Flight time is the time the plane is
| scheduled to take off, which means the flight time would
| diverge from the boarding time, and then you'd once again
| be asking why the boarding time is different from the
| flight time and why they don't let you board until the
| flight time, rinse and repeat.
| IshKebab wrote:
| Sounds like you're describing some impossible system but
| that _is_ how it works in the rest of the world. There 's
| a time at which the gates close, and if you're at the
| gate before then then you can go on the flight. If not
| then they _might_ wait for you for a bit if you 've
| already checked in but nothing is guaranteed.
|
| They can still go early if all of the passengers have
| boarded.
|
| I got to Dublin airport once at the time that the gates
| were supposed to close and they said they would wait for
| us if we were fast... Got to the concourse and it was the
| furthest gate possible - the sign said to allow a 15
| minute walk! Had to run all the way but we made it.
| digisign wrote:
| United is famous for its customer service. I have a few good
| ones myself, but won't bore you.
| quacked wrote:
| If you think that airline customer service stories are
| boring, then I request that you do your best to bore me.
| assbuttbuttass wrote:
| They managed to board all the other passengers in less than 5
| minutes? In my experience boarding takes at least half an
| hour just for everybody to sit down. Was the flight
| exceptionally empty?
| trelliscoded wrote:
| They may be queued up in the jet bridge. I've been stuck
| inside one after the doors closed while we waited for
| everyone to get into the plane.
| kitsunesoba wrote:
| And here I am feeling unsatisfied about the ~20MB size of the app
| I'm responsible for. I haven't seriously tried to cut its size
| down yet, but aspirationally I'd like to cut that in half.
|
| Probably doesn't make that much of a difference in the long run,
| but I have a theory that smaller binary sizes increase chances of
| any given user being up-to-date, thus increasing the percentage
| of the userbase that's running the latest version at any point in
| time. iOS tends to pull updates while charging, and so an app
| that's 10MB is more likely to get updated during a brief charging
| period than an app 50x as large, especially if the user in
| question has a slower connection.
|
| It also makes for smoother troubleshooting when the user can pop
| into the App Store page for your app and have the app updated
| almost instantly.
| pinephoneguy wrote:
| Meanwhile the KaiOS store doesn't even allow apps larger than
| ~50mb for larger devices.
| mzs wrote:
| tldr; strip
| jshchnz wrote:
| This is awesome to hear! I'm actually one of the founders of
| Emerge Tools (mentioned in the blog post), we work on helping
| teams just like United fix problems like this. I had actually
| tweeted at United in April of last year letting them know about
| these issues:
| https://twitter.com/jshchnz/status/1379154466872549377
|
| If anyone at United wants help, happy to chat!
| josh@emergetools.com
| TrianguloY wrote:
| On android, the default Hello World example when you load Android
| studio takes more that 1MB, and it's a single screen with two
| words displayed.
|
| The same ninja-optimized app can be less than 1kb. All the
| useless space is taken by libraries, features "just in case" like
| login and assets, and more runtime generic things.
|
| Supposedly all that generic stuff should help for more complex
| apps, so for a very simple app the ratio used/unused is very
| high, but for more advanced apps it is low which means that the
| size of apps should not be linear with complexity
|
| ...yet they are, because the more complex an app is the more
| useless libraries are included.
| bnycum wrote:
| I really thought that app size would be a hinderance because of
| the cellular download limits (at least because I only remember to
| download these apps while at the airport). So I had to look it up
| and it appears there isn't a size limit anymore from Apple as of
| 2019, just a popup asking you to allow a download over 200MB.
|
| https://9to5mac.com/2019/06/03/ios-13-removes-200-mb-file-si...
| lkxijlewlf wrote:
| Mediocre developers being mediocre developers. What else is there
| to say?
| StillBored wrote:
| Apple should have never allowed these "non-compiled"
| applications. An LTO like pass/etc would rip out tons of size too
| simply by removing all the unused code.
|
| BTW: The last couple times I've run into this, they say use the
| app, but there has been a plex/etc like http video server on the
| onboard Wifi network which can just stream to random
| browsers/PCs/etc. I've yet to have any DRM/etc issues, although I
| suspect that might be part of why they want to push people to
| dedicated apps. A large number of people though just use their
| locked down work laptops/etc so they will have a problem when
| they cut off that path.
| ksec wrote:
| There is a whole Node.js runtime for iOS included?
|
| I would imagine this is basically an Electron for iOS and
| Android? If that is case I am not surprised at the file size.
| ziggus wrote:
| Is it an Electron app?
| toomuchtodo wrote:
| While not a security bug, this should still be some sort of
| bounty amount worthy.
| mojuba wrote:
| But even the stripped version is way way too much for an app like
| this. I can imagine it's layers upon layers of poor, bad and
| terrible architectural and organizational decisions.
| bastardoperator wrote:
| Couple bad development practices with archaic technology for
| ticketing and we get the worst of both worlds. I've worked with
| two airlines and it was fairly frightening to see what type of
| BS they're working with and against.
| stingraycharles wrote:
| I'd like to approach this differently, and think about what it
| would have cost United Airlines to do it "the right way",
| versus what value it brings them.
|
| I'm the first to say that this utter bloat is terrible, but
| most people aren't really bothered by it. And I can only
| imagine that they outsourced their app development completely
| and like to keep costs low.
|
| From that perspective, it's probably much more pragmatic to fix
| the problem at the root(s): Apple may want to mandate stripped
| binaries (I think this is also what RPM does by default, just
| strip everything), and/or god forbid these Electron-type
| frameworks should make things more efficient.
| cush wrote:
| Who are most people? Most people in the world are data-
| restrained in one way or another. Depending on the market,
| this can have serious user impact.
| colechristensen wrote:
| There's an opposite direction to look at it.
|
| Taking the shortest path to achieve a goal often seems like
| the good idea, but it leads to bloat and inefficiency. It'd
| take longer to "do it right" so you never do it right.
|
| But you ignore the fact that all that bloat actually costs
| you to maintain it. "Not fixing it" is always faster and will
| always be the shortest path to the next feature... but that
| next feature gets harder and harder to achieve as the bloat
| grows. The bloat makes the fastest thing slower and slower
| while the fastest thing is always ignoring the bloat.
|
| When you _appropriately_ choose when to fix, when to focus on
| efficiency, everything becomes faster.
|
| The concept is slowing down to move faster.
|
| There's avoiding premature optimization and then there's
| ignoring optimization forever except for extreme emergencies.
| engmgrmgr wrote:
| The "right way" also needs to be maintained and refactored
| over time. That gets increasingly expensive the more in-
| house or low-level things are.
| sneak wrote:
| If Apple would allow web notifications, most apps wouldn't
| need to be apps at all, but could simply be webpages that get
| bookmarked to the launcher. The UX for the user would be, for
| most non-game apps, identical.
|
| The problem is that purchases would no longer be subject to
| Apple's 10x industry standard (30% instead of 3%) captive
| credit card payment processing service (for apps), so no web
| notifications in MobileSafari that might undermine platform
| control and payment processing monopoly. Apple, of course,
| will say this is about protecting users from notification
| spam, and sidestep the inconvenient facts that it protects an
| Apple cash cow and locks developers and users into a closed
| and proprietary platform.
| nouveaux wrote:
| "The UX for the user would be, for most non-game apps,
| identical."
|
| In theory, this is true. In practice, it's just hit or
| miss. I think it's just hard to maintain web across all the
| different platform and screen sizes. It's probably due to
| the fact that an iOS developer specializes in one platform
| and most web development shops will have to support all
| platforms.
|
| "If Apple would allow web notifications"
|
| I do not use apps because of notifications. I use apps
| because in general, the performance and experience is much
| better.
| sneak wrote:
| It's also hard to maintain two entirely separate apps in
| two entirely different languages for two entirely
| different platforms/APIs, all while giving up nearly a
| third of your CLV to a rentseeking middleman.
| nouveaux wrote:
| I completely agree. I'm just sharing my experience. I
| wish web apps were better so we don't have to download so
| many apps.
| jacobr1 wrote:
| What we need is better support "native hybrid" apps.
|
| For example, you can create "app" that is just a link to
| browser. There are plenty of action you don't want random
| web-apps to perform due to security/sandboxing issues,
| but if you can grant explicit permissions that issue goes
| away. It is one of the reasons think like election exist.
| But could apple/goog provide a better electron that was
| built into the OS?
| arcticbull wrote:
| I strongly suspect the bulk of this 500MB is DRM frameworks
| for their in-flight video playback that they can't or don't
| want to support in-browser. Safari kicks video playback
| over to the United app each time you select something to
| watch and it does what appears to be a multi-stage hand-off
| dance.
| RussianCow wrote:
| Ahh, that explains why I can never get it working in
| Firefox on my Android tablet.
| ajsnigrutin wrote:
| I doubt it...
|
| Even apps without notifications are still apps, because
| they can take additional data from users, sometimes even
| location and the whole address book.
|
| Look at sites like reddit for exmaple, which purpusefully
| cripple the mobile web experience to get the user to
| install the app.
| sneak wrote:
| The web supports location and photo picker and camera
| APIs and most apps don't access your address book.
| arcticbull wrote:
| > I'd like to approach this differently, and think about what
| it would have cost United Airlines to do it "the right way",
| versus what value it brings them.
|
| For a 5-screen 50MB app, sure. For a 5-screen 500MB app that
| falls pretty flat.
|
| [edit] You could fit all of Tony Hawk's Pro Skater 2 or Final
| Fantasy VII for PS2 in the same amount of space.
| andai wrote:
| Windows 95 required 4MB of RAM and 50-55MB of disk space.
| Krustopolis wrote:
| And sucked.
| anthk wrote:
| Windows 2000 was much more stable and yet the install was
| far less than a GB. On RAM, with 128 MB was pretty
| snappy.
| barbecue_sauce wrote:
| Ahem, FFVII and THPS2 are Playstation One (PSX) games.
| anthk wrote:
| You could fit a good chunk of N64 zipped ROMs under a
| 700MB (a CD).
|
| An emulator and Mario 64, Zelda OOT, ISS and 40 games
| more could be placed under a CD and yet you could fit a
| good bunch of MP3's in between.
| arcticbull wrote:
| The shame, lol. Your feedback is well deserved.
| throw10920 wrote:
| Exactly - _badness of waste is non-linear_. An application
| that 's 4x as large as necessary is more than twice as bad
| as one that's 2x as large as necessary.
|
| A candy bar which is 5% packaging and 95% candy by mass is
| alright. A candy bar which is 50% packaging and 50% candy
| is horrifying.
| fennecfoxen wrote:
| It's not _that_ scary.
|
| https://www.sugarfina.com/valentines-day-mini-candy-trunk
| jandrese wrote:
| "The Right Way" involves running the strip command before
| sending the app off to Apple for publishing. It's 5 seconds
| of effort and saves almost 200MB for literally thousands of
| users.
| tinus_hn wrote:
| You'd think the right way would involve Apple refusing your
| app if it is wasting users storage because you couldn't be
| bothered to strip your binaries.
| bspammer wrote:
| I'm willing to bet that the devs who made this app have
| never worked with a decompiler and have no idea what
| "symbols" are. Source: I am one of those people (well I
| have a vague idea, but certainly wouldn't think to check if
| that was causing bloat in my iOS app).
| rvnx wrote:
| Contrarian opinion here; I understand their logic. It looks
| like a rational trade-off that the engineers have done.
|
| Increase developer productivity at the expense of hardware.
|
| In this case, engineering is more expensive than hardware
| (because hardware is at the cost of the user).
|
| The smallest iPhone starts at 128 GB. This means the
| application takes 500/128000 blocks: 0.4% of the total device
| storage.
|
| Over time, the iPhones are going to have more and more
| storage. So, if app size is a problem, and over time, the
| problem is fixed by itself, why would you invest engineering
| resources into that ?
|
| You have X engineers with Y amount of working hours, and tons
| of important things to do. Yes, probably fixing a problem
| that brings a low amount of complains from end users at the
| cost of productivity isn't high on the list for them.
|
| EDIT: Possibly interesting source:
| https://www.androidauthority.com/average-smartphone-
| storage-...
| dogleash wrote:
| >Contrarian opinion here; I understand their logic. It
| looks like a rational trade-off that the engineers have
| done.
|
| This is not a contrarian opinion. This is the default
| attitude in web, cloud hosted, and mobile app development.
|
| >looks like a rational trade-off that the engineers have
| done
|
| What are your back-of-the-envelope numbers? Or are you just
| shrugging and assuming that performance has zero impact on
| the development loop, so therefore no development effort
| should be expended on it?
| mquander wrote:
| When someone starts looking into why it's so big and they
| immediately discover a huge dumb mistake (the example in
| the post), why do you assume that the rest of the app size
| is because of rational tradeoffs, instead of being more
| dumb mistakes?
| gpderetta wrote:
| Perfect example of Wirth's Law in action, sadly.
| athorax wrote:
| This kind of bloat doesn't just affect storage usage, for
| people with capped data plans these kind of apps are a
| nightmare
| ratww wrote:
| It's especially worse for people who are traveling.
| notahacker wrote:
| Yep. Airlines are one of the few brand apps where there
| probably _is_ a significant business case for spending
| developer time optimising an app for download size, since
| customers who make the decision to try to download United
| 's app on slow or metered connections at the airport or
| overseas are probably customers ready to be upsold stuff
| via the app.
| xorcist wrote:
| > Increase developer productivity at the expense of
| hardware
|
| Only this is almost never true.
|
| If it's possible to do something unnecessarily complicated,
| someone will inevitably do it. Maintenance costs are often
| greater as complexity and bloat goes up.
|
| Longer compile times and generally greater development
| cycle latency also tends to decrease developer productivity
| more than the small time differences might suggest.
| throw10920 wrote:
| > The smallest iPhone starts at 128 GB.
|
| The smallest iPhone _sold now_ is 128 GB. The iPhone 5C,
| sold in 2015, had 8 GB internal storage with no expansion
| options. 439 MiB is a full 5% of the _total storage
| capacity_ of the iPhone 5C, completely ignoring the amount
| reserved for the OS that 's completely unusable to the
| user.
|
| The logic used here hurts lower-income people and
| contributes to climate change by encouraging poor use of
| device resources -> shorter device lifetimes -> more
| e-waste and wasted energy.
| bouke wrote:
| And even 2 of those 8 GiB were taken up by the OS. So
| that leaves just 6 GiB. Now we're already at 7%. That's
| valuable storage that you cannot use to fill with holiday
| pictures.
| Nition wrote:
| I had the 8GB iPhone 5C. The OS (iOS 10) actually took up
| nearly 4GB of that 8GB.
| tut-urut-utut wrote:
| People with 7-year-old phones are not really a target
| group a company selling luxury stuff is going to bother
| optimizing for.
| jnovek wrote:
| The iPhone is _not_ a luxury product; not in America,
| anyway.
|
| More than half of American smartphones in 2021 were
| iPhones. The iPhone is price-comparable to its Android
| contemporaries. The Android downmarket in the U.S. is a
| minority by a wide margin.
| yuliyp wrote:
| United Airlines is not a luxury product.
| dymk wrote:
| Flying anywhere, period, is a luxury
| TillE wrote:
| I don't know if you're trying to make a point about
| global living standards (irrelevant) or the non-necessity
| of air travel (true, but also irrelevant), but the fact
| is that budget airlines have existed for decades, and are
| often comparable in price to a bus trip.
| morcheeba wrote:
| Flying is far cheaper than Amtrak.
| gbear605 wrote:
| For a lot of trips, Amtrak is about the same as flying.
| Looking at a round trip from NYC to Chicago, on the
| arbitrary dates of March 26 to April 9, Amtrak costs $180
| while Kayak shows the cheapest flights at $159. Of
| course, Amtrak takes much longer (20 hours) but is less
| hassle, and at that price the flight only lets you take
| one carry-on while Amtrak lets you bring two checked bags
| and two carry-ons. Adding checked bags will add $60 for
| the first and $80 for the second. Amtrak is also better
| for the environment if that matters to you, and the price
| difference is about the same as the cost of the carbon
| offset for the flight.
|
| Overall, choosing Amtrak or flying is perfectly
| reasonable in different situations. Amtrak could
| definitely be improved a lot though!
| aledalgrande wrote:
| Flying in NA, with covid, is a luxury. Europe is a
| different story.
|
| Edit: why the downvotes? You can get flights for 50 bucks
| to go to different countries in Europe.
| Symbiote wrote:
| Maybe people don't believe it.
|
| The cheapest flight I can see on SouthWest.com is $60,
| for a 1 hour journey from Atlanta to South Carolina.
|
| The cheapest flight with Ryanair from Copenhagen is $9,
| though it doesn't include checked luggage. It's also an
| hour.
|
| An even cheaper one is Krakow to Eindhoven, 2 hours, $6.
| There are fewer dates for this price though.
| addaon wrote:
| Southwest is not really the equivalent of Ryan. Spirit
| airlines has plenty of $22.22 flights (for two's-day, I
| guess), glancing at their page today. This includes e.g.
| Chicago to Tampa, Texas to NJ, and other flights longer
| than most European flights.
| ben_w wrote:
| I've been on a flight between Berlin and London that cost
| less than an Amtrak return ticket from Davis to
| Sacramento, and I've also been on a multi-day road trip
| from Davis to Salt Lake City that, while fun, was only a
| good financial choice due to four people squeezing into a
| Prius.
|
| While I enjoyed camping and seeing bits of the US that
| foreigners like me don't normally see, it's not entirely
| clear that the difference between that and flying makes
| flying the luxury.
| aledalgrande wrote:
| In general flying is more expensive in NA because of less
| competition and bigger distances. That's what I noticed
| when I moved from Europe to here. Now you have to take
| expensive tests to fly international both ways. That's
| why I consider it a luxury.
| bmicraft wrote:
| Flying often enough to justify even installing the
| app/getting any benefits from it surely does count as
| luxury flying though?
| ben_w wrote:
| Ideally an app is sufficient low friction that even a
| really minor quality of life improvement justifies it.
|
| Not being an American I have no reason to even be a UA
| customer let alone install the app, and therefore I don't
| know if they've achieved this or not.
| dylan604 wrote:
| Flying that much in anything less than first class is no
| where near luxury.
| JohnJamesRambo wrote:
| Why would you ever want to discourage someone from buying
| what you are selling?
| pgwhalen wrote:
| When the cost of selling to such a niche group outweighs
| the revenue, that's the premise of this thread.
| thorncorona wrote:
| Perhaps not but everyone saying this is what kills
| accessibility for those who need it. This is the same
| argument made by companies to not support deaf/blind
| people.
|
| Requirements are often above average in some dimensions
| and below average in others.
|
| If we optimize for people who are wealthy, always in high
| bandwidth areas with new phones, etc etc soon we will
| have left most people behind.
| WJW wrote:
| > a company selling luxury stuff
|
| Leaving people behind is the entire concept of selling
| luxury stuff though, so I still don't think that the
| companies will care much.
| selfhoster11 wrote:
| The assumption here is that a luxury-oriented audience
| would always want the latest phone. I disagree with that.
| If I'm rich, I might just not care about upgrading
| because I have better things to do. Or I like this
| particular 7 year old phone, so I keep it.
| anamax wrote:
| I use a 32GB Android.
|
| A significant fraction of that 32GB is taken by system
| crap, so a GB makes a difference.
| sitzkrieg wrote:
| you didnt factor in the mobilw bandwidth to download this
| oversized crap constantly. with 1gb plans in mind how many
| downloads a month do you get to instagib a plan like that?
| and for what, no actual patch notes ever?! at least most
| apps dont hard lock you out when they detect being behind
| Banana699 wrote:
| This bizarre reasoning puzzles and infuriates me so much.
| The linked post shaves more than 40% of an app's size in 5
| minutes, by doing nothing but being curious about the half-
| gigabyte app and knowing how to use a couple of tools.
|
| This is not a case of "I have plenty of water so let the
| kids splash some in the playground to have fun", this is a
| case of "I have plenty of water so I will load 10000 liters
| in a truck and drive 1000 kilometers and back just to dump
| them in the desert for no fucking reason".
|
| Seriously, 5 minutes? I spend more than that in the
| bathroom. How many 5-minutes is a "Scrum standup"? a
| "progress meeting" ? a <insert bullshit corporate activity
| here>? Do all of those things not waste the engineers'
| time?
|
| I'm trying to imagine the world if every profession and
| craft tried to justify this disgustingly irresponsible
| mindset :
|
| " - This combustion engine uses an inferior injection
| mechanism that wastes 40% more fuel compared to latest...
|
| = Don't waste my time!!! I have more important things to
| worry about.
|
| -.... It would take 5 minutes to fix
|
| = Customers don't notice the fuel consumption anyway, so
| that means robbing them out of money with inferior
| engineering is okay. Now hurry up, we'll miss the daily
| 3-hours progress meeting. "
|
| If only Donald Knuth knew what " Forget about the small
| efficiencies" would be used to justify.
| ironmagma wrote:
| There's probably an observability bias here. It could be
| that the app sizes would be 3x worse, if no one ever
| tried. You would never know, because you only see the app
| sizes after people have done the work.
| rixed wrote:
| I share your feeling. Day by day I feel more guilty of
| belonging to that industry because of the laziness,
| sloppiness, negligence, acceptance of spying, of dark
| patterns, etc, and I do not disclose what I'm doing for a
| living more readily than I would if I worked for some
| mafia.
| IggleSniggle wrote:
| Yeah no, clearly false, because my iPhone has 8 GB and that
| ought to be plenty. Hope your web app works on my phone,
| 'cause I'm not installing a bullshit app with that much
| bloat.
| tschwimmer wrote:
| This is not the most relevant tradeoff. The United App is
| the only way to watch in-flight entertainment on many
| United Flights (esp. on newer planes without seatback
| screens). Every time I fly United, they make an
| announcement that says "Make sure to download the app
| before we take off because you can't do it once we're in
| the air!" and then I see everyone whip out their phones and
| tablets. Usually that's 10m or so before we lose cell
| reception and it's often not enough time to fully download
| the app.
|
| I've often thought that they either need to cache the app
| locally on the plane itself or provide a special free
| passthrough on the in-flight wifi, but so far they haven't
| provided either. In any case, app size is crucially
| important for the key use case that many (most?) people use
| the United App.
| bluedino wrote:
| > I've often thought that they either need to cache the
| app locally
|
| It's not that simple, but it makes total sense to cache a
| 500MB app when they have a couple TB (?) of videos on the
| plan.
| eppsilon wrote:
| Maybe Apple could provide some way to cache apps on a
| local network without needing a Mac. (macOS has a content
| caching option in the Sharing prefpane.) They could add
| the same thing to iOS/tvOS to make it cheaper and more
| widely available. Ideally there would be a containerized
| version of the service that could run on any Linux-ish
| device...can't imagine Apple doing that though.
| ratww wrote:
| But this company can't even be bothered to even strip
| symbols. Having Apple allow caching + putting this in
| every airplane is a way more difficult.
|
| Maybe we as an industry should start doing the boring
| parts instead of jumping into shiny tasks that take 10x,
| 100x the time it would take to solve the original
| issue...
| hadlock wrote:
| Also the only way to order adult beverages
| aserafini wrote:
| But the problem is not only storage but also bandwidth (on
| a runway).
| acchow wrote:
| > The smallest iPhone starts at 128 GB
|
| You can buy a brand new, unlocked iPhone 12 from Apple. It
| starts at 64GB for $729
|
| https://www.apple.com/shop/buy-iphone/iphone-12
| addaon wrote:
| The iPhone 11 and iPhone SE are also both available, new,
| with 64GB.
| PascLeRasc wrote:
| There's no app as valuable to me as 2-3 albums or 400
| photos.
| retrac wrote:
| > So, if app size is a problem, and over time, the problem
| is fixed by itself, why would you invest engineering
| resources into that ?
|
| You are assuming apps won't scale larger over time. The old
| addage about software expanding to consume all available
| resources comes to mind. I remember thinking I'd never be
| able to fill my first 1 GB hard drive with software. And
| now it takes half that for the simplest things. As the
| bytes get cheaper we ration them less.
| astrobe_ wrote:
| Here is today's car analogy : well sure, they pollute, but
| if nobody complains why would car makers invest in cleaner,
| more efficient motors? Oil is cheap anyway and will be
| cheaper in the future (that's probably what they thought in
| the '60). Oh, wait...
|
| A friend of mine told me their company is trying to
| downsize their flash storage in order to come back to the
| unit prices of before the shortages.
| jakub_g wrote:
| > what it would have cost United Airlines to do it "the
| right way", versus what value it brings them
|
| It may depend on the app, but Uber noticed that the bigger
| the app, the fewer people install it, unsurprisingly.
|
| I also had friends who wouldn't install Signal because they
| don't have any space left on the device, and they stick to
| Whatsapp/Messenger which they already have.
|
| https://eng.uber.com/how-uber-deals-with-large-ios-app-
| size/
|
| > App-download-size restriction means first-time users
| cannot download the app ... when they are not on Wi-Fi.
|
| > We established a correlation between the Uber Rider app
| size and customer engagement -- when the app size crosses
| the download size limit, and it leads to a 10% reduction in
| app installations, 12% reduction in sign-ups, and 20%
| reduction in first-time bookings, resulting in revenue
| loss.
|
| > Over the past three years, the Uber Rider app's size has
| often approached the App store's over-the-air download
| limit, and staying below it is a clear priority.
| eithed wrote:
| I'm no mobile developer, but why wouldn't stripping out
| symbols be default behaviour that publishing process
| performs?
| stingraycharles wrote:
| I can imagine that in case of app crashes, having debug
| symbols makes debugging them much easier.
|
| Other than that, there's unlikely to be a reason.
| dceddia wrote:
| This is maybe part of it, but having shipped a macOS app
| that's stripped of symbols, crashes can still be debugged
| as long as I've got the dSYM file that was made at build
| time, so I don't think it's a super strong argument.
| Tools like Sentry will catch the crashes and symbolicate
| them for you, if you've provided them with the dSYM. It
| can be done on the local machine too.
| [deleted]
| chrisseaton wrote:
| > I can imagine it's layers upon layers of poor, bad and
| terrible architectural and organizational decisions.
|
| Or are they trade-offs?
|
| Do these 'bad decisions' actually impact their business or are
| they manageable, allowing them to achieve their mission,
| focusing on other things that are more important?
| MetaWhirledPeas wrote:
| Without diving into specifics we'll never know of course. But
| consider the opposite: would _good_ decisions positively or
| negatively impact their business? Would they prevent them
| from achieving their mission or focusing on other things?
|
| I can think of how bad decisions could negatively impact
| their mission and focus:
|
| - App is slow and buggy, pressuring users to choose a
| different service altogether
|
| - A much larger support staff is required to handle customer
| issues
|
| - Bugs are painful to address and require weeks or months to
| resolve
|
| - Developers spend more time fixing bugs and less time
| working on features, resulting in delayed features and an
| increased team size to allow more parallel development
| _fat_santa wrote:
| I've worked on one of these apps (healthcare space, just
| checked and the size sits at 350MB). Here's the problem as I
| saw it firsthand:
|
| * Far too many hands in the pot: My rough calculation is at
| any given time, there are around 1000 contributors to this
| app, across various teams. This itself is not a problem, but
| leads to issues.
|
| * Tech Debt Racks up Quick: Again because there are so many
| hands in the pot, tech debt racks up unbelievably quickly.
| And furthermore it's almost impossible to address because it
| cuts accross so many teams and orgs.
|
| * The Solution? More Hands in the Pot!: With tech debt
| racking up quick and not being resolved, productivity grinds
| to a halt. App has constant errors, crashes, and things like
| hot reloading are just totally broken because of all the
| underlying issues. So what do you do when faced with this
| problem? More engineers! Rather than addressing the problems
| that face developers, they just throw more labor at the
| problem, compounding the previous issues.
|
| * Code Duplication: With so many folks working on the project
| but not talking to one another, code duplication becomes a
| MAJOR issue. Say you have a "Button" component that needs to
| be modified. Well, modifying that component means going
| through 5+ teams to get approval. So to sidestep you create
| "Button2", and the next guys creates "Button3". The result is
| you pull up the fuzzy finder and search "Button", only to get
| 15 results with subtle differences.
|
| This is just my experience. Currently this app is top 20 in
| healthcare on the Apple Appstore. The company also has a
| number of other apps and when I was leaving the company,
| there were talks to merge all the apps into the "main" app
| (good fucking luck).
| Friday_ wrote:
| Maybe they bundle movie inside app.
| [deleted]
| kingcharles wrote:
| This seems like a huge market opportunity for a service where
| you upload your "final" binary and some app goes through the
| thing and shows you all the stupid you are doing and how to fix
| it.
|
| This would have really pissed me off if I had to download it
| over my cell plan. I have one phone with minimum apps on it
| which I use for day-to-day, and then another with all the
| scummy bloated apps on it, but the data plan on that phone is
| small and 500MB would be a huge chunk out of my monthly quota.
| hammock wrote:
| As a frequent and mostly non-loyal flier, I can say despite all
| its faults the United app is far and away the best airline app
| in the US: fast, easy to navigate, powerful, useful and often
| pleasantly surprising. American is the only other app that
| compares, I can't stand to use any other airlines' apps.
| thaway2839 wrote:
| One could argue that maybe the developers of the app were
| optimizing for the right things. Usability, performance,
| etc., as opposed to disk space.
| jacobr1 wrote:
| As a long time united frequent flyer, while I have many
| gripes, they have consistently made the app better and
| better without useless "redesigns for the sake for
| redesigns"
| PragmaticPulp wrote:
| In this case, shipping symbols with the app is almost
| certainly an oversight. Stripping symbols of shipped
| binaries is standard good practice.
|
| That said, I don't think the difference between a 40MB app
| and a 400MB app is all that critical these days. Optimizing
| for development speed and user experience over an
| absolutely minimal download size is a reasonable choice.
| nyanpasu64 wrote:
| Shipping a 40MB app instead of <10 MB is questionable
| except for large apps; Dolphin on Android emulates an
| entire GameCube/Wii, yet the APK is only 16 MB (34.7 MB
| extracted). Shipping a 400MB app is _shameful_.
| potatolicious wrote:
| Not to mention the surface area of the app is often
| larger than it appears to a single user, especially for
| companies this large whose customer bases are this wide.
|
| It's tempting to think about the United app as something
| very simple:
|
| - Search for flights
|
| - Run through the booking flow for flights
|
| - Look up existing bookings
|
| - Change existing bookings
|
| But this ignores a lot of scope that's actually critical
| for a company whose products are very complicated:
|
| - ID verification for international travel
|
| - Custom functionality for large institutional cu stomers
| (government, corporate)
|
| - Functionality for ancillary services: in-air streaming
| entertainment, in-airport services like lounges and
| baggage checks, loyalty program, loyalty-tier-specific
| functionality like priority connections.
|
| - ... etc.
|
| In this case the lack of stripping symbols seems like a
| very easy win and definitely is an example of sloppiness,
| but the idea that the binary should definitively be <
| 100MB seems to ignore a lot of scope.
| gopher_space wrote:
| The tl;dr was halfway through the article.
|
| > pushing code into frameworks has been a best practice for a
| while
| MikeCapone wrote:
| I think the Stripe app is like 20 megs, Overcast even smaller
| than that.
| dont__panic wrote:
| Just checked the other day: one of my favorite apps this
| year, Hyperweb, is just 18.2 MB. Granted, it's only a browser
| extension for adblocking, styling, etc (sort of a replacement
| for all of the various Firefox addons I wish I could use on
| iOS), but the competition, AdGuard, clocks in at nearly 500
| MB.
|
| I really wonder what some of these apps are doing with this
| space. My banking app clocks in at 400 MB as well.
| andai wrote:
| My favorite iOS app, Decoupled, is 2.4MB. My favorite
| Android apps were 5-10x smaller.
| ryandrake wrote:
| Just for some perspective, the entire installer package for
| the Shareware version Doom took up about 2.39MB of space.
| This included the EXE and all art assets. The installer for
| WordPerfect 5.1 (DOS) was about 3.6MB. The full on-disk
| footprint of Microsoft Office 95 was less than 100MB,
| including all documentation, Word, Excel, and PowerPoint.
|
| I'm not entirely convinced value-per-byte is a measure of
| software quality that a lot of users care about, but it
| undeniably trends down every year.
| bombcar wrote:
| The one I like is that the Finder icon on macOS is larger
| than the entire _system_ on the original Mac.
| testplzignore wrote:
| DOOM2.WAD has always been my measuring stick for software
| size, as I remember how frustrating it was to download
| such a huge file (15MB!) in the dial-up days. I never did
| get it to complete - I couldn't justify to my parents
| that the phone line would be busy for a whole day :)
| PascLeRasc wrote:
| Thanks for recommending Hyperweb, you've just saved me a
| ton of space.
| dont__panic wrote:
| Keep in mind that even on the free version, you can add
| (unlimited?) adlists. I've added some of the most popular
| uBlock Origin default lists to mine to make the ad
| blocking even better. It is absolutely insane how many
| apps Hyperweb replaced for me, too!
| pgalvin wrote:
| I have AdGuard on my phone at ~60MB, you might want to
| check that.
| dont__panic wrote:
| Strange, the download from the app store
| (https://apps.apple.com/us/app/adguard-adblock-
| privacy/id1047...) is 100 MB, but my install somehow
| crept up to ~400 (logs, maybe?) over a couple of years of
| use. I don't have it installed any more, but it's wild
| how much this varies across devices. What phone do you
| use? I use a 2016 SE, I wonder if there's a bug that's
| consume extra space on a device as old (and likely
| untested by AdGuard) as mine?
| tyingq wrote:
| I don't think the Stripe app is a good comparison. Airline
| apps have to cover shopping, booking, cancellations, seat
| selection, loyalty programs, check-in, bar code generation
| and scanning, and so on. Typically with broad support for
| different currencies, languages, etc, etc. 439mb is obviously
| not right, but I would expect the app to be fairly large.
| arcticbull wrote:
| > Airline apps have to cover shopping, booking,
| cancellations, seat selection, loyalty programs, check-in,
| bar code generation and scanning, and so on.
|
| All of that happens online.
| tyingq wrote:
| That may be true for some airlines (webviews vs native),
| but it is not true for many. Boarding passes are probably
| a good example. It's very typical for that functionality
| to use something like Apple Wallet integration, and also
| native widgets to upsell cross-sell boarding/seat
| upgrades, etc.
| arcticbull wrote:
| While broadly fair, one minor quip, I believe all Wallet
| passes have to come down from the server. Apps can't make
| their own, can they?
| tyingq wrote:
| Passes already in the wallet don't require you to be
| online. But, what I meant was that there was additional
| code, thus additional size for all the functionality and
| ui related to boarding passes, whether or not parts of it
| don't work offline.
|
| At least the airlines I've worked with prefer native code
| and UIs for any flow that's either revenue-producing, or
| likely to create issues on day-of-travel. They tend to
| use webviews only for things that don't have to be
| working to sell a ticket or board the aircraft.
| markus_zhang wrote:
| I think one needs to understand the mentalities of the project
| managers and programmers/contractors who actually work for
| those behemoth corporations to understand the quality of their
| work.
| andai wrote:
| Similar article by same author (2017):
| https://news.ycombinator.com/item?id=14901051
| willis936 wrote:
| With all of these complaints about app size I have to wonder: why
| has everyone heralded the era of static linking?
| account-5 wrote:
| Out of interest having never been on an airline that forced you
| to install an app to get what is now a basic customer service,
| what happens if you don't have a phone that supports their app?
| Do you get a discount?
| Arrath wrote:
| You know the answer.
|
| In fact it's quite the opposite, as another poster mentioned:
| they will offer to rent you an airline ipad for the flight so
| you can enjoy their content at a little extra fee.
| dorianmariefr wrote:
| Maybe they pushed a debug build instead of a release build?
| melony wrote:
| Does iOS not have code splitting? I thought most of iOS app bloat
| comes from the multiscreen assets. I surprised compiled code
| takes up so much space.
| grishka wrote:
| Do iOS apps still use bitmap graphics?
| O-stevns wrote:
| In many cases yes, but svg support has been available in
| xcode since ver. 12 and before that pdf had been available.
| As a consultant I haven't worked on a project yet where
| vector assets has been chosen over bitmap
| perardi wrote:
| But does Xcode convert PDF and SVG to various PNG assets?
|
| https://bjango.com/articles/svgassetcatalogs/
|
| It's my understanding, as a designer, that it was auto-
| generating 2x and 3x PNGs as from your vector assets, and
| that's what actually got bundled in the final app--and that
| PNG compression was _not good_ compared to what I could get
| by going through ImageOptim.
|
| I would be quite happy to be wrong about that. It would
| save me a lot of time.
| mrweasel wrote:
| Ignoring the economy of the development process, vs. just being
| able to push out an app quickly, I cannot help wonder how small,
| and fast apps like this could be, without losing features.
|
| Sure stripping out symbols is a quick thing you can do, but how
| about eliminating the ad tech stuff (people already bought the
| ticket, leave them alone). Remove the dependency of 3rd. party
| libraries and frameworks, utilizing only the built in frameworks
| (or does that not make difference in iOS applications?).
| hnburnsy wrote:
| Check the article there is code for Soduku.
| Scoundreller wrote:
| App, OS and other file sizes are big deals in bandwidth-
| constrained environments. Canada has a number of remote
| communities with satellite uplinks, so every update means the
| whole town needs to download them independently.
|
| While some cos have "appliances" that ISPs can install that'll
| dramatically reduce back haul bandwidth usage, I'm unaware of any
| that make any that work for a small community or aircraft. SSL
| really impacted the use of general-purpose proxies to save
| bandwidth. Maybe more torrent-based schemes for app stores and
| others could fill this gap.
|
| > Apple also supports incremental downloads, meaning you can
| download a "diff" of app binaries in some cases (also amazing!),
| but this is even harder to measure on an actual device. In my
| case I was trying to download the United app for the first time
| on a runway before my flight took off.
|
| What would be interesting is if Apple did this diff between apps,
| since I'm sure a lot share frameworks and other bits.
| silverfrost wrote:
| mb and MB - beings out the pedant in me...
| [deleted]
| commandlinefan wrote:
| > it is fair to say this area of app development is complicated
| to understand.
|
| Not really, but it's also actively suppressed. If they can make
| as much money with a 439MB app as they can with a 10MB app, why
| would they waste any time or effort trying to save you a few
| minutes of download time? If anything, I expect this to get
| worse, as management is constantly pushing for adoption of
| frameworks that (in their imagination) speed up time-to-market.
| digikata wrote:
| They spend a lot of money trying to offer competitive features
| on their flights - like maybe watching streaming videos on the
| plane enabled by the app. To the extent that passengers can't
| finish a 439MB download of the app just before they board, the
| app size wastes investments in services of the airline.
| spookthesunset wrote:
| Don't these airplane steaming services have a local copy of
| all the movies on some storage device inside the plane?
|
| I wonder how crazy it would be to cache the iOS app... like
| maybe they run a caching transparent proxy on the plane... or
| some crazy relationship with a CDN that treats each plane as
| an edge node.
|
| I dunno, it would probably be pretty be way to expensive to
| set up something like that to be worthwhile.
| Kon-Peki wrote:
| Apple content caching is built into MacOS. A Mac mini
| connected to the in-plane wifi would likely do the trick.
|
| https://support.apple.com/guide/mac-help/what-is-content-
| cac...
|
| https://support.apple.com/en-us/HT204675
| commandlinefan wrote:
| You're thinking like an engineer, not a manager. How does
| this factor into this year's bonus?
| digikata wrote:
| Increase of passenger engagement metrics on app delivered
| video services?
| snovv_crash wrote:
| If more people download and run the app, then surely you
| can justify further investment in the product?
| bitwize wrote:
| Southwest has a webapp, lol.
| psanford wrote:
| The size of the app is hurting their on-boarding funnel, they
| just can't see it. The most likely place you are going to
| download the United App is in the airport just before your
| flight, on mediocre free wifi.
|
| United really wants that download to be fast, so customers can
| get the app before getting on the plane. Otherwise you end up
| with a bunch of grumpy people your that your flight attendants
| have to deal with.
| engmgrmgr wrote:
| I've been able to download the app over plane WiFi for free.
| It used to be a little-known hack for free internet once upon
| a time.
| hrrsn wrote:
| That'd probably work a whole lot better if the app wasn't
| 439MB.
|
| I've been on a few budget carrier flights that have skipped
| the headrest display for an airline app. They haven't had
| external Internet access, as it's just served over a local
| WiFi connection from an onboard server, so you must install
| the app before you take off.
| PascLeRasc wrote:
| Flight attendants don't report to software engineering
| managers though.
| psanford wrote:
| Yes, its an organizational problem, but one that a healthy
| company should be able to figure out.
| gingericha wrote:
| It's likely to also be one of the first apps I decide to
| uninstall when my phone's storage becomes somewhat limited.
| Symbiote wrote:
| Looking through the old texts I have from my phone provider, it
| would cost me EUR4 to download even 10MB over roaming data if I
| was in the USA ("Welcome to USA ... data is EUR0.40/MB"). That
| might be worthwhile in some cases.
|
| If I'd perhaps been connecting from a different country with
| United flights, there's no way I'd download it over roaming
| data "Welcome to Jamaica ... data is EUR3.05/MB".
| 10000truths wrote:
| Actively suppressed by whom? Is there some shadowy cabal of
| executive saboteurs gleefully cackling at the idea of getting
| away with a bloated app? Because it's plainly obvious that a
| bloated app benefits neither the consumer nor the business.
|
| It costs consumer time waiting for a large app to download, and
| it wastes consumer money by burning up quota on metered
| connections. It costs the business because apps have a size
| limit, and hitting those limits means no more features until
| you can reduce that size.
| morpheuskafka wrote:
| > It's becoming somewhat of a popular trend in the airline
| industry to cut costs by having the passenger bring the hardware,
|
| I mean, there's virtually no one taking a flight without at least
| a phone if not a laptop/tablet with them, and most of them
| probably have a much better screen and headphone support then
| whatever outdated stuff would be built in to the plane.
|
| The only thing I really miss on flights that don't have the seat
| backs is the thing that shows the altitude and progress on the
| map.
| chrisseaton wrote:
| > The only thing I really miss on flights that don't have the
| seat backs is the thing that shows the altitude and progress on
| the map.
|
| But you can get that on their app as well.
|
| I think flights should do-away with in-seat entertainment. I
| very rarely see anyone using them, and if you are unfortunate
| enough to be in economy, they actually take up quite a lot of
| your personal space.
|
| All the screens must weigh a ton as well - bad for the
| environment.
| coldcode wrote:
| I spent the last ten years of my career building iOS apps, all
| but one you would likely known at the time, and whoever in charge
| of this app is an idiot. Shipping an app to the general public
| with symbols intact? Really? If they didn't know/didn't care, it
| tells me no one there likely cared about any other quality issue
| either. It's highly likely that any relevant lead person probably
| screamed about this daily, but higher ups don't give a shit.
|
| At my last job our legal team would have had a cow shipping
| labels. Our apps are gleaned by blogs looking for scoops on
| upcoming features.
|
| I once interviewed at a major airline (not United) and at the
| time they had outsourced their entire app and web to some foreign
| companies, including any and all oversight. Their app was a POS
| and they had hired someone to write a new one -- the same
| company. Now they had no idea why it was so delayed so they
| wanted to hire someone to embed in the other company to spy on
| what was going on. Of course I wanted nothing to do with this
| travesty. This was years ago, no idea what happened.
|
| You'd be amazed at how pathetic mobile development can be even at
| big companies. Mobile doesn't have to be hard, but if management
| tries hard enough, can make crap at scale.
| pinot wrote:
| I travel on United probably 6 flights a month on average.
| Overall I think it's a pretty good app but like anything I use
| routinely, I could easily come up with a list of 10 complaints,
| from a UX perspective.
|
| My biggest is the UI only considers one half of a RT "trip" a
| trip.
| squeaky-clean wrote:
| > I once interviewed at a major airline (not United) and at the
| time they had outsourced their entire app and web to some
| foreign companies, including any and all oversight
|
| Oh it goes deeper than that. Almost every airline (Southwest is
| the only exception coming to mins at the moment) also
| outsources their web design, their pricing structure, and their
| availability tracking. I've worked with several airlines that
| legitimately could not give us a list of all their current
| routes. Some of them actually paid us to scrape their website
| and tell them where they're currently flying and how much it
| cost on average.
| kylehotchkiss wrote:
| I like what Duffel is doing as far as creating a nice,
| consistent airline booking API goes: https://duffel.com/
|
| Maybe some carriers should integrate with Duffel and build
| their apps on top of the Duffel API instead of shipping all
| the logic off to accenture or whatever
| coldcode wrote:
| Duffel is interesting, I wonder what they use on their back
| end. I've written airline booking API when I was at an OTA
| (now sadly gone like so many) on top of our parent
| company's res system. It can be complex, made more in my
| case so by the pathetic res system itself and its
| limitations. In fact at the time we had no way to do test
| bookings without real money (and mostly un-refundable
| except for a single route).
| hogrider wrote:
| It's an airline. Of course they dgaf.
| varenc wrote:
| Speaking of United shipping apps with symbols intact...
|
| Last week I came across some unminified JS on United's
| website[0]. I love the warning it starts with:
| /* Minification failed. Returning unminified contents.
| (5218,49-69): run-time error JS1300: Strict-mode does not allow
| assignment to undefined variables: nearbySearchErrorMsg
| */
|
| Never seen a minifier fail by not minifying before. Also
| interesting seeing all the commented out code and TODOs.
|
| [0] https://www.united.com/ual/bundles/js/flightsearchresults
| JTon wrote:
| TL;DR:
|
| > Wow! I honestly wasn't expecting that much of an improvement.
| We shaved 187MB off the app size in five minutes by stripping
| framework symbols.
| anthk wrote:
| C++ and Go binaries such as mednafen can be about 50% smaller
| once stripped.
| 0xbadcafebee wrote:
| > While the United dev team should have noticed this much earlier
|
| I suspect it's more that their devs are either junior and don't
| know any better, or more likely that they just don't care. I've
| also met some devs who believe whatever comments they read on HN,
| like "file/memory size don't matter"
| bluedino wrote:
| They don't teach this at iOS boot camp
| paxys wrote:
| They will care if they are paid to care. It's as simple as
| that.
| NelsonMinar wrote:
| It's 78MB on Android (Pixel 6 Pro). That's one of the hidden
| advantages of Android: much smaller apps. Makes for faster
| downloads, less storage consumption, and maybe even better
| caching / performance. It's common for iOS apps to be 4-5x bigger
| than Android apps.
| hnburnsy wrote:
| For me the download from Play store is 78 MB, but it expands to
| 237MB once installed (One Plus 6T Android 11).
| hnburnsy wrote:
| Southwest app is 41MB installed. I know it does have a video
| player installed as Southwest let you stream from the
| browser.
| sagivo wrote:
| This is why I always prefer simple mobile web version over
| installing apps. There's no added value for the app that I cannot
| get from a simple browser.
| ngoel36 wrote:
| File size aside, I can confidently say - United hands down has
| the best app of any major airline in the world. It's better than
| their website and often-times even better than calling customer
| service on their 1K (top loyalty status) line. Many ways to make
| it better, but if we're comparing it to airlines & hotels, it's
| extremely well done.
| 121789 wrote:
| I agree. And it used to be the worst out of any of them, so
| props to their dev team.
|
| The video player does give me problems sometimes though
| pinot wrote:
| It absolutely should _know_ that I'm a X-elite member
| blahblah stop giving me ads for their credit card which I've
| had for 15 years.
| notyourwork wrote:
| Interesting, I've found Delta's app to be usable (above
| average?). Sort of funny that a usable app is my above average
| rating but I've found Delta's app just doesn't get in the way.
| I'm looking forward to trying United.
| bluedino wrote:
| The Spirit app installs a bitcoin miner.
| MH15 wrote:
| I usually fly Spirit right now (college student) so I'd
| love to see a source for this.
| blah_humbug wrote:
| I've found that true of other everyday things (eg, booking a
| session my local gym), and find it incredibly depressing. Not
| only have we devised a world where impersonal, digital
| communication is the way things get done, but we must also buy
| a smartphone to even start accessing it.
| brianwawok wrote:
| I find it a great step forward in society, for every Gym in
| the world to not need to staff someone to sit there and
| answer phone call questions around (what are your hours? can
| I book X for Y?). Those are done much faster with robots and
| lower our costs.
| ciphol wrote:
| Those are done much better with a web site (for many
| purposes, a static website with no Javascript is
| sufficient!) than by downloading a gigantic possibly-
| insecure app.
| trevorLane wrote:
| have you seen Breeze's app?
| jaywalk wrote:
| "Sorry, your device's memory is too low. Start your search
| again." -Delta app
| sidlls wrote:
| Reminds me of Facebook's (in?)famous "Apple can't handle our
| scale" thing:
| https://www.reddit.com/r/programming/comments/3m5n2n/faceboo...
|
| There was an HN thread about it, too, but I can't find it.
| ChrisMarshallNY wrote:
| I've talked with folks that have worked on their code.
|
| I think that it's unreasonable to expect a Lambo (or even a
| Yugo) to accommodate a 300Kg man.
| ChrisMarshallNY wrote:
| I found this: https://news.ycombinator.com/item?id=10275396
|
| But no comments, and no votes, so it must have been another
| thread, thereabouts. It was quite some years ago.
| scandinavian wrote:
| I found the PDF if anyone is curious.
|
| https://drive.google.com/file/d/16lDaCfEjT7Z72EEDFBo5r3lTDCV...
|
| I'm not sure what I just read though.
| password4321 wrote:
| 2014 (Android) - https://news.ycombinator.com/item?id=8162342
|
| 2015 (scale) - https://news.ycombinator.com/item?id=10271586
| https://news.ycombinator.com/item?id=10066338
|
| 2018 (491MB) - https://news.ycombinator.com/item?id=17995954
|
| 2020 (Messenger) -
| https://news.ycombinator.com/item?id=22466462
|
| 2020 (SDK) - https://news.ycombinator.com/item?id=23790207
| indrora wrote:
| When Windows 10 Mobile was a thing, Microsoft had written a
| very competent Facebook application to go along with it.
|
| The original version was 18MB. The official Facebook-written
| version was nearly 300MB, with the bonus that it disabled the
| old app.
|
| I wrote about it then: https://medium.com/hackernoon/how-not-
| to-transition-an-app-b...
| barrkel wrote:
| The real problem is that people no longer understand the
| abstractions they're using to build apps.
| sayrer wrote:
| You can't paste your password on United's inflight WiFi portal. I
| eventually got it to work by making Safari share it from my
| laptop to my phone.
| throw10920 wrote:
| Every time I see an article like this, it's another point of
| evidence that, no, large application sizes are _not_ actually
| needed for performance /functionality/ease of development -
| they're just due to sloppy programming.
|
| Electron and web developers, take note.
| allisdust wrote:
| Even after optimization its massive. What does this app contain?
| An Embedded game? Shouldn't an airline app be simple.
| polpo wrote:
| Especially since a large number of people are probably
| downloading the app in a panic at the airport on crappy
| overloaded WiFi or cell signal.
| wnoise wrote:
| Yes, actually. You can see "sudoku" in one of the listings.
| jrc2022 wrote:
| Nicely done! Someone should send this to UA...
| lulzury wrote:
| What is the purpose of having those framework symbols there in
| the first place? What was the original intent/use?
| joezydeco wrote:
| Upstream telemetry on a crash?
| Siecje wrote:
| Debugging
| galad87 wrote:
| No purpose. Even without those, you can resymbolicate a crash
| log later.
| _3u10 wrote:
| You are very incorrect sir. I encourage you to strip the
| frameworks in your /System folder and then reboot your
| system.
|
| You can strip the main executable but stripping frameworks is
| a VERY VERY bad idea.
| galad87 wrote:
| There is no framework to strip in the /System folder,
| everything is in the shared dylib cache since Big Sur.
| [deleted]
| [deleted]
| anon_9867864 wrote:
| Apple. Hire this man!
| VBprogrammer wrote:
| It's times like these that I'm reminded our first computer had a
| 1GB hard-drive.
| Narishma wrote:
| Mine was 40MB and I couldn't imagine what to fill it up with.
| DrBazza wrote:
| Hello world by size -
| https://drewdevault.com/2020/01/04/Slow.html
|
| 439Mb? That's horrific.
|
| If I was cynical, I'd say it's in Apple's interests to have
| bloaty apps, so they can sell more expensive phones with more
| storage and memory.
|
| But that would be cynical.
|
| It feels like a failure at every step in the tool chain if a
| binary comes out at that size.
| squeaky-clean wrote:
| Not that it excuses it, but having worked at a place that did
| contractual web design for airlines, I'd bet money that the app
| wasn't developed by any employees at United and instead was
| developed by the lowest bidding external company they could find.
|
| Based on some of the names of packages I don't recognize
| (CYFDCTEncoder) and some googling I'm going to guess the company
| was CYFuture.
| abotsis wrote:
| I wonder what effect stripping has on crash dump reports though.
| I don't know enough about how the App Store manages those, like
| (if a user opts in to "share information with the developer"),
| does the developer get less nice dumps as a result of stripping?
| Surely this can be worked around so long as someone has a symbol
| table (which they likely do), but the infrastructure might not be
| in place to do that automatically.
| ajconway wrote:
| Debug symbols are stored separately on the developer's computer
| (and may be uploaded to Apple, but that's optional). Including
| symbols in the App Store binary is practically useless.
| hoten wrote:
| Is there any reason Apple couldn't just strip the code
| binaries themselves?
| mlindner wrote:
| A good crash dump doesn't need symbols at all. The symbols come
| from the stored symbols from when the author originally
| compiled it. As long as the builds are reproducible you can
| even produce the symbols at a later date for an old version if
| you still have the source code.
| snovv_crash wrote:
| Even if the builds aren't reproducible, rebuilding on the
| same machine with the same settings usually gives you
| something a crash dump will work with.
|
| But, make your builds reproducible and/or save your debug
| symbols as part of your release process, it will be something
| you wish you did otherwise when you're not quite sure if the
| stack trace you have is correct.
___________________________________________________________________
(page generated 2022-02-23 23:01 UTC)