This is still an app!

ByTales Pinheiro in

ATTENTION: The following text may contain some low slang words…

I recently received the following pages somewhere:

The basic premise of both: you do not need a gigantic amount of Javascript, CSS, tracking, analytics, etc. To make a website. You do not need a giant dynamic banner, advertisements, and a whole bunch of “content” that only makes the site heavier, consumes the user’s bandwidth and franchise, and shows no relevant content. This has become such a problem that ad blockers have been created – tools that eliminate advertisements from web pages and show only the true useful content. And, more recently, ad blockers have also been made available to mobile devices – which has become a problem for the sites since most of them make money from these ads. This has led sites to develop anti-add-blocker solutions. And so it follows the cat-and-mouse life.

As I work with iOS apps, I’ve been thinking about it. In times of iPhone 6s with a camera capable of filming in 4K, we still have devices with 16GB of storage. Then the iPhone owner has two options: uninstall most apps to get some pictures, or not uninstall and not take the photo of the family lunch or filming the 2 year old child playing with the puppy. I think this is not the option he chooses. What, then, can we do about it? Decrease our apps, of course!

I went hunting the size of some apps in the App Store. Let’s see the result.

Let’s look at some national applications now:

  • SafraNet – Safra Bank application, has 16MB, but seems to be just a webview, meaning all content as assets is online, being downloaded on demand.
  • Banco do Brasil has 22MB (as far as I know, one of the most integrated Brazilian banks apps with iOS).
  • Itaú 30 Hours has 35MB.
  • Nubank – the fintech of the moment, has 40MB.
  • Bradesco has 65MB – and as far as I know it also has several features like webviews, as well as Safra.
  • Original Bank – another bank that wants to run 100% by the mobile – has 76MB.

Now the real reason to worry about it’s the size of the apps:

  • Twitter (official client) has 126MB.
  • Facebook has incredible 214MB.

How much assets does the official Twitter app have more than Tweetbot to be 10x larger? What does a social networking client like Facebook have to be almost bigger than two browsers and one GPS app TOGETHER?A built-in browser it does not have, since it uses Safari’s system …

Initially, Apple limited the download of updates via 3G / 4G to a maximum of 50MB. Above that, the upgrade should be done via Wi-Fi. But recently this limit has been expanded to 100MB. So maybe these apps would not launch such frequent and huge updates … Storage is “cheap”. Data via GSM not.

Since iOS 9 we have a set of features called App Thinning, composed of 3 separate technologies:

  • App Slicing: In general, we submit to the store packages containing images used by all Apple devices, but why does an iPhone 4s user need to download optimized images to iPad Pro? Why does the iPad need to download iPhone images? With this functionality, this is avoided by separating the sets of images for each device. This means that other devices do not need to download that set of audio, video or images.
  • On Demand Resources: Not all features – audio files and images, among others – are required at the time of opening the app. With this feature, we can mark sets of files that will be downloaded only when the user reaches a certain screen. This decreases the initial download, and if the user never accesses this app functionality the content is never downloaded. But once the download has been made, the device accesses directly without having to re-download – other than a cache, which can be cleaned and require re-download.
  • BitCode: When submitting the application to the store, we send a package with compiled binaries for an intermediate representation of the processor. So a user with iPhone 4s – and older CPU – downloads only the executable compatible with their CPU – generated on demand on Apple servers, without the need to include binaries optimized for the iPad Pro.

Now we can see part of why Tweetbot is so small, and Twitter and Facebook are so big: Tweetbot is optimized for iOS 9, using and abusing the Thinning App. Facebook still has support for iOS 7 (if we consider that Facebook has 1.59 billion users, with 65% of them accessing daily, and that 2.03% of iOS users still use previous versions of iOS 8, we have possibly 21 million iOS 7 users accessing Facebook daily. Hardly they will discard support for these devices, but this does not justify such a large application with bi-weekly updates. Even with an incremental download – another feature that makes it easy to download updates – the Facebook app has about 110MB of average updates.

Another important point in application size is the unrestrained use of third-party SDKs. I recently talked to a friend who works in an app with about 5 or 6 different analytics tools because different teams in the company are accustomed to using different tools. Then one of them was giving trouble, and he left asking who used that tool. He did not find anyone. Someone in the past said: “puts, the tool looks cool, let’s use” and puft! He removed the analytics tool, eliminated a source of crashes and no one within the company realized. I already worked on an app that almost doubled in size for the simple fact of using Realm as a database, and then realized that it was killing fly with cannon fire, because for that functionality a simple SQLite – already built into the app – or even a small cache (des) locally archiving the objects would be sufficient.

But is it only in the size of the binary that we can help the user? No! APIs can also be very optimized. I recently went through a mobile commerce customer who used a “ready” back-end, a product of a large company, and had an API developed by a third-party company. One of the biggest customer complaints about the app was slowness. Early part of my job there was to identify what caused this. With Charles Proxy on hand, I went to analyze the data traffic.

The response from the first request was 64KB. That’s just JSON, which did not include the images. This request was made each time the user displayed the application’s home page. Opened the app: 64KB + images of a 10 products (which also were not optimized). It went into a product, returned to the home page, plus 64KB of response (at least the app used a cache library and the images were not downloaded again). For a list that should contain data of about 10 or 20 products, 64KB is MUCH! And there’s more. By entering the product details page – something that should list the data needed to display that detail page – the answer included details of 18 other products! I do not remember exactly what it was, but it was something like six recommended products for the user, six of “who bought that product you are seeing was also interested in those” and six “products with sales blaring!”. But it was not just the list with the minimum information needed: name, size, price, image link. They were all the details of 18 products that were not even displayed in the application – this data was only useful to those who accessed via browser – again, without discriminating whether it was a browser on the phone or computer.

This was an extreme case, which leaves the app slow and consumes a lot of franchise – noting that there is still a gigantic portion in Brazil of people who have daily non-cumulative 10MB franchises. But optimizing APIs is as important a step as optimizing the app – maybe even more important, since the app only drops once, but a bad API you consume every time the app is used.

So remembering the two links at the beginning of the article: you do not have to send unnecessary data, unnecessary images, build bad APIs, include third-party libraries, and a bunch of analytics tools. This is still a fuc&$*.. app. ?

Leave a comment! 0

read more