Your app’s growth is correlated to how it uses resources

Negative app user experiences hurt app developers

I tried to customize Facebook #2016yearinreview generated video on an iPhone app but it kept crashing every time I scrolled through 30 or 40 photos while selecting a photo. I gave up on this feature and even selected the option to stop seeing 2016 year in reviews videos.

A single negative experience a user has with your app can have serious consequences.  People may altogether stop using your app and possibly uninstall it.  Negative experiences may also translate to bad reviews on the app store.

App publishers should pay special attention to providing an exceptional experience to their users.  Apps like Snapchat go out of their way to detect low memory, low battery, high network latency and low power battery mode.  The app automatically adjusts its usage of resources.

Tracking positive and negative experiences in an app and acting on them is a proven way to retain, engage and grow your app.

Top 3 resources to use judiciously

To provide the best experience to your app users, the top three resources your app should consider are

  • Memory,
  • Battery (or Energy) and
  • Network bandwidth


Apple provides a standalone tool Instruments as part of the Xcode development suite, which is highly recommended during app development to help uncover issues early in the app development cycle.  You build the app with profiling and run Instruments.  Instruments collects data as it profiles, and presents the results to you in detail for analysis.

Screen Shot 2016-12-14 at 10.02.04 PM.png

Memory management

Typically, there are very few reasons that memory leaks can occur in ARC environment.

  1. Retain Cycles or Strong Reference to other objects
    For example: If A ➜ B ➜ C ➜ A
    i.e. A object has strong reference to one or more objects and in turn it has been strong referenced by Object C. ARC cannot release this kind of object memory handling. Use Weak References instead.
  2. Core foundation objects
    These are low-level classes which doesn’t support ARC. If you are dealing with these objects, the Manual Memory Management should be done or we can transfer the object ownership to Objective-C objects. Use Bridge transfer object ownership

The Instruments tool provided with Xcode can give you valuable insight into the lifetime of objects used throughout your application.  To get started, connect your testing device. (It’s best to use a real device for this, since the Simulator doesn’t always behave like a real device, especially when it comes to low-level details.) Then, in Xcode, go to Product ➜ Profile, which will compile your app and start Instruments.

Developers often see leaks when it comes to view controller management. They may think they moved to a new controller, releasing the old controller, but it was never deallocated. This can leave a ton of objects behind. It pays to just run through your app with the leaks tool to clean up any inadvertent strong reference cycles.

When creating an SDK it is even more important that memory be checked appropriately. Memory leak in SDK affects apps that rely on it. Handling low memory warnings in all classes is highly recommended.

Simulating a Memory Leak:



Calls that apps make to internet or server should be efficient, asynchronously handled secure over HTTPS/TLS and robust to ensure the performance of an app.

If the requirement called for real-time data, use optimized system APIs.  For non realtime consider batch processing. Users may not always be in cellular network service area, so store and forward mechanisms work well.

Always try to use network payload as small as possible and use data-compression techniques to reduce the user’s network bandwidth by adopting gzip encoding.

If the app needs to download significant amount of data from a server, consider warning the users when she is on a cellular network.

In order to profile and manage the network performance then, in Xcode, go to Product ➜ Profile, which will compile your app and start Instruments. Select ‘Network’ as below.


Battery / Energy

Always be considerate of user’s phone battery.  For instance, avoid polling or requesting frequently for resources like Location updates. When possible, postpone battery intensive tasks or perform batch processing to reduce the drain the users’ phone battery.

Use Instruments ‘Energy Log’ for checking battery consumption as shown below.

Screen Shot 2016-12-14 at 9.00.15 PM.png

The Energy Diagnostics profiling template monitors factors that affect energy usage on an iOS device, including CPU activity, network activity, screen brightness, and more. Identify the areas where usage is highest, and see if you can reduce impact in those areas.

For example, you might find opportunities to defer discretionary or network tasks until more energy efficient times, such as when the device is plugged in or on Wi-Fi.

Monitoring and Analyzing using Instruments

To monitor or analyze the above discussed attributes follow the steps describe below.

  1. Launch Instruments and create a new trace document that targets your device and app with the profiling template
    [For example: ‘Leaks’, ‘Energy Log’, ‘Network’ etc].
  2. Click the Record button or press Command-R to begin recording a trace.
  3. Use the app normally on the device, while allowing data to be collected.
  4. Click the Stop button or press Command-R again when complete.
  5. Go through the collected data and look for spikes or areas of otherwise unusual or unexpected activity.
    Then, review the code in these areas to determine whether improvements can be made. If there are ‘Red’ colored spikes or symbols observed that means, there are awry things needs to be fixed in the code.


Your app’s growth is strongly correlated to how it use resources.  Apps that detect low memory, low battery, high network latency and operation in low power battery mode, offer better experiences to users and keep users engaged and retained.  Retention and Engagement are the two most important factors responsible for app growth.