Hill88 2.2.2 — How we’re fixing the latest app launch crashes
This post was originally published on Mar 13th, 2014
Today we have released Hill88 2.2.2 which fixes all known issues related to Asana’s recent changes regarding completed tasks, including much faster syncing and multiple improvements and fixes which are described in detail at the end of this post.
We have intensively stress-tested this version with a large group of our amazing beta testers during the last couple days, and while most issues have been fixed, there is still a very small number of users experiencing the app crashing at launch. After multiple thorough investigations, we have discovered that the cause for these crashes was increased memory usage, which forces the OS to terminate the application. As the issue is memory related, users with older devices, such as the iPhone 4, iPhone 4S and some times the iPhone 5, are more likely to experience the app launch crash issue.
How does the memory issue manifest itself
The following is based on all the information that we have received from our users, as well as through our own testing, and may not be related to the actual issue.
When we started developing Hill88 2, we had to make a decision about the technology to use for persisting cached data to make the app as efficient and flexible as possible.
The flexibility to create a lot of custom scenarios due to the way we receive data from Asana’s public API was the reason to go for a so called binary store or memory store. That means that all cached data is stored in one binary file and loaded into memory when the app is launched.
The benefit of doing it that way is enormous flexibility and performance, as nothing needs to load from disc while using the app and almost any custom data can be stored without being forced to any specific scheme. Not to mention the benefits when dealing with that data on different threads without blocking the UI.
However, the huge disadvantage, which we obviously underestimated, is that memory is limited and iOS is very strict with managing available memory for apps currently active as well as running in the background. If an app uses more memory than then OS makes available to the app, then it receives a friendly memory warning and very soon after gets terminated. That doesn’t seem to be an issue with Apple’s latest devices, however, with older ones it definitely is.
That’s exactly what happens when you see the launch screen for about 10–15 seconds and then the app returns to the springboard. While loading cached data, the app hits the memory limit set by the OS and is forced to terminate, and if our latest user reports are any indication, that issue might have gotten even worse since the release of iOS7.1 (even though we have intensively tested iOS7.1 betas).
What we are doing about it
There are basically two different actions we are taking at the moment.
Investigating & testing
We are still wondering why that issue just started to happen (at least our users started to communicate that issue) quite recently when Asana changed certain behaviors and features on their service. We still believe that the chosen way of persisting data should be more than feasible taking the number of persisted objects into account and therefore we continue to investigate and test the current implementation and hope to find the reason why suddenly memory usage increases.
Implementing a traditional database
However, there is a plan B which is actually switching the binary store over to a traditional database, which allows incremental loading of data, keeping the memory usage more or less independent of the total amount of data. As you can imagine, that’s not something that’s done in a day or so, as that goes quite deep into the core of the entire app. We make good progress, but all the custom scenarios that are forced by the architecture of Asana and it’s public API (and have been the reason for using a binary store in the first place), are more than challenging (at least for the functionality that we want to offer with Hill88). It’s difficult to estimate the total time required for this implementation, so we won’t do that right now. We will update this post along the way as we get a better feeling about the progress.
What you can do to minimize your chances of running into this issue
If you experience the app launch crash as described, there are a few steps that you could give a try in order to keep memory usage as low as possible, potentially avoiding the app getting terminated at launch:
As Asana’s API doesn’t support the inbox yet, there is a lot syncing and data manipulation happening in order to make the inbox possible.
When you newly install version 2.2.2 (our latest release), the inbox is disabled by default. Otherwise, you can disable the inbox in the settings menu.
Disable background app refresh
iOS7's new background app refresh feature is used in order to keep the data up to date. That’s important for the inbox as well as having the latest tasks available when you open the app. However, background refresh may sync data that you actually never look at. So in order to keep the synced data to a minimum, you can disable app refresh for Hill88 in the OS settings under “General”.
Don’t show archived projects
As for syncing in the background, syncing archived projects might create more data than is actually required. So in case you have “Show archived enabled”, disabling it in the app’s settings could massively reduce the cached data amounts.
Update 1 — March 29th, 2014
After 2 weeks of intensive testing and debugging, we have identified the inbox feature as the causing issue for the increased memory usage that has lead for many of our users to crashes when launching the app.
As a result we have temporarily removed the inbox feature along other fixes and improvements to keep the memory usage as low as possible.
Today, the latest version has been released to our beta testers in order to confirm that the issue has been fixed and if we don’t get any negative feedback on that issue, we will submit the update for app review shortly.
Once it’s confirmed that the inbox has indeed caused that issue, we will publish a separate blog post on all the details around the inbox feature and why it causes the memory to increase so dramatically.
Update 2 — March 31st, 2014
Our internal tests as well as the feedback from our beta testers confirmed that the inbox feature was the causing issue for the app launch crashes. As a result of that finding, we have temporarily removed the Inbox (and notification) feature in order to fix the issue as quick as possible to release an update for our affected users. As mentioned in the previous update, we are going to publish a separate detailed blog post on the subject of the inbox as well as notification feature.
Update 3 — April 2nd, 2014
Version 2.2.3 (fixing the app launch crash) has just been approved by Apple and is now available for download from the App Store. Please delete the app before installing the latest version, in order to make sure that there is no cached data that keeps the app crashing at launch.
News, improvements & bug fixes in 2.2.2
- New setting to enable/disable inbox (by default disabled for new installs)
- Optimizations for syncing of orphaned tasks
- Optimizations of cached data
- Assignee status gets automatically set to today when due date set to today
- Removed “Add Project” and “Add Tag” from favorite section
- Fixed issue where comment input would be displaced when containing multiple lines of text and losing keyboard focus
- Fixed caching issue that could lead to app crashes
- Fixed issue where cached data would be cleared when app logging out due to failed refresh of authorization
- Fixed issue related to completed tasks
- Fixed issue with background fetch
- Fixed issue where sync could lock when suspended from Asana when hitting the rate limit
- Various other UI modifications
- Various other bug fixes
- Various other performance optimizations