Since the advent of iMessage Read Receipts, there have been a lot of mixed feelings about them. Some people like them while others think they’re creepy as all hell. I’ve always had them on because I have a fairly liberal view of my privacy and don’t really think that it’s that big of a deal.
Usually, I like to have them enabled to let whomever I am communicating with to know that I’ve read and acknowledged their message. If you’re talking to a fairly reasonable person, and you didn’t get back to them right away, the logical conclusion they should draw is that you saw the message but don’t have time to respond right away. Maybe you were driving or in a situation that you can’t reply immediately.
Anyway, all of these problems or misunderstandings can be alleviated with one simple tweak: SafeTexting by Aaron Thomas, which is $1.00 on the BigBoss repo or SafeTexting Lite which is free with a limited feature set. The paid version allows you to chose when to send the Read Receipts and hide your typing indicator.
Head on over to Cydia and check out the lite version to give it a shot if you’re interested.
When Apple introduced the new and improved App Switcher in iOS 7 it gave people the ability to easily close apps by swiping up on the preview card. Something happened where a large portion of people with iPhones became obsessed with swiping up and killing apps; almost as if they’re afraid of seeing them in the App Switcher at all. In this article, I will be covering what your iPhone is doing in the background, why you shouldn’t kill apps, and the exceptions for when you should.
I would also like to mention that the inspiration and most of the technical content of this article came from reddit user Secretss, who was kind enough to let me turn her write-up into an article.
To get started we will get some vocabulary out of the way by defining some terms relevant to iOS’s background memory management.
Backgrounding Capability
The grace period for background tasks in iOS is 10 minutes, which is set by default is the system’s configuration. That said, the app itself may be coded to have a shorter limit. This is what happens to your apps if they have backgrounding capability:
Foreground app gets minimized. (home button is pressed)
iOS to app, “Ok bro, you need to sleep now.”
App to iOS, “No wait! I’m not tired, I still have something to do!”
iOS to app, “Alright you have 10 minutes, then it’s bedtime.”
App does stuff/waits around.
10 minutes later, or sooner if the app is done with it’s activities it goes into hibernation, gets shelved and removed from active memory.
The above only applies if the app isn’t doing the following:
Using location services.
Giving navigation directions.
Using VoIP to wait for incoming calls.
Recording audio.
Playing music or in a call.
If the app falls into one of the categories above, then it will the app will stay in the background indefinitely. A example of when it’s a good idea to kill an app is after you’ve used navigation, but no longer need it (think: Google Maps). If you keep it open it’s going to be constantly requesting your location and therefore using up that precious battery.
There is speculation that some third-party navigation apps will go to sleep by themselves if left in the background too long or the phone is locked.
Background App Refresh (BAR):
This is a whole other thing that works outside of the 10 minutes grace period. An app with BAR enabled is allowed to wake up every now and then until it’s quit from the app switcher or the phone resprings/reboots. There is no 10 minute restriction here, and it’s important to understand that BAR is different from backgrounding. By “wakes up” I mean “opens a sleepy eye and downloads some stuff, then goes straight back to sleep”. If you kill the app from the app switcher, its BAR privilege is gone as well.
BAR-enabled apps are usually scheduled to wake up at opportune moments to update themselves. These moments include:
When the device is actively in use.
When the device is connected to wifi and/or a power source.
When a push notification for the app is received.
When location changes.
From Apple: “iOS learns patterns based on your use of the device and tries to predict when an app should be BAR-updated in the background. It also learns when the device is typically inactive, such as during the night, to reduce update frequency when the device is not in use.”
Another Reddit user, Niruga, mentions here that there is also what is called a “silent” push notification that apps can make use of to wake their app up for BAR-updates. Silent push notifications are not seen by the user. He provides the link to a post on Apple’s Developer Library on Push Notifications.
For example, Dropbox makes use of BAR and location to keep its photo upload working past 10 minutes for as long as it takes to finish uploading. It won’t be constantly uploading, since that’s not what BAR does. So what’s happening in Dropbox is that it uses location changes to make the app wake up and upload for 10 minutes before it goes to back to sleep, then waits for the next location change to make the app wake up again and continue where it left off, and repeat until all uploading is done, all without the user having to keep the app open in the foreground.
To decide whether or not to enable BAR, think about whether you trust the app developers not to abuse the function.
Stay tuned tomorrow for part two, where I’ll cover on what happens when you kill an app from your app switcher. Also, be sure to read my final thoughts and some tips as well in part two.
Yesterday in part one of this mini-series I covered what happens when you close out of app without killing it, and Background App Refresh which allows apps to download and update data in the background. To finish things up, in part two I’ll be covering what happens when you kill an app permanently (swiping up on the app in the app switcher) along with some final thoughts and things to consider if you kill apps on a regular basis.
Killing an App:
When iOS itself (not the user) terminates an app it is meant to shelf the app in its current state. It is like pouring liquid nitrogen all over a LEGO play set in its current mess and then chucking that masterpiece on a shelf. It’s removed from the play area (active memory) and isn’t taking up system resources anymore. When it’s opened again, the LEGOs are magically thawed and you continue with the mess. Here it is in Apple’s words.
The user terminating by swiping the app from the app switcher is like sweeping every LEGO piece into a box, and filing the box back in the warehouse in alphabetical order. When you want to open it again, the system has to spend more juice/resources to locate the box, pull it out, open the lid and set everything up. Even without demanding it to return to the artsy mess you had it in before, this still takes more energy – because unfreezing it is really just that much less effort for the system.
When you swipe and remove an app from the app switcher, the app is terminated/force-closed, and is packed up neatly into a box and filed away into the warehouse. When you next open that app from the warehouse, various processes happen (credit: Ryan Petrich): AppleID is verified, the app is decryped, the binaries loaded into memory, and UIKit is initiated. All these processes are just to get a blank app window to show on your screen without pulling/loading the contents and data. Battery is used to do this every time you open an app afresh. You may save the 10 minutes of background battery by swiping an app before it suspends, but consideration should be made on a per-app basis whether this 10 minutes of battery saved is more than the battery used on relaunching afresh.
Sometimes suspended apps may get terminated by the system due to large active processes. The system can handle this, so let it do its job.
However, sometimes you’d find that if the app had been frozen and shelved for long enough, it will eventually get swept up in a box as well. From Allan Kerr, the developer of Watchdog:
Some applications will reload after sometime due to how individual developers implement backgrounding.
Here is a video made by Secretss explaining everything with a neat hand made visual aid to follow along with.
Final Thoughts
Okay, now we know about Background Capability, Background App Refresh, and what it means to kill an app. To go a little further, you can think about what apps you might use frequently that utilize these features of iOS and if you trust the developers to implement them correctly. If you take a little bit of time to reflect on what is outlined in this article and how it relates to your app usage, you might be surprised with what you learn.
Do you trust Facebook’s app developers to responsibly use it’s VoIP privileges? Would it be in their interest to keep the function running over your battery life? How many apps do you have Background App Refresh enabled for and why? Are you using these features?
Most importantly what apps do you use everyday, multiple times a day? These are the apps that you absolutely do not want to kill unless they stop functioning in some way or another. A couple examples of when I will kill one of these, are when Alien Blue, my favorite Reddit client, stops loading something or when the Messages app bugs out and won’t come out of landscape mode.
I swipe up without thinking of the consequences in these cases because it’s getting in the way of the user experience. I can personally say that I haven’t killed all of the apps in my switcher for years now and I have only seen an improvement to my device’s overall performance and battery life.
Let iOS do it’s job of creepily learning your habits and perform it’s state of the art memory management techniques. Apple may be known for it’s premium prices for hardware, but that comes with a lessor known compatibility with their software. Android handsets may ship with more RAM and faster CPU’s, but Apple’s flagship consistently benchmarks the same or higher year after year.
If you take anything away from this article, at take a moment to think about what was covered and see if you have it within yourself to try something new and stop swiping those apps!
Notifications for Reddit is a simple new app developed by Andrew Chang (/u/RedBanHammer) that does just one thing and does it very well — real push notifications for everyone’s favorite social bookmarking site. Currently, it is $0.99 for the launch special and will go up to $1.99 shortly after. Strangely though, this is the first app that has push notifications for Reddit. When I say “push notifications” I don’t mean enabling background refresh to occasionally fetch your messages from Reddit servers while simultaneously gobbling down half of your battery life in the process. With this app you don’t even have to have background app refresh enabled, all the heavy lifting is done by his servers, and it simply delivers your messages when they are received. He has even integrated several Reddit apps including Alien Blue, AMRC, Biscuit, and up and coming Apollo so that when you tap on the message it will open your favorite client. It’s also a fairly decent inbox manager for Reddit, although the original plan was to just enable the push notification to open other apps. When he discovered the limitations of open messages within those other apps he chose to develop an inbox client as well.
When you open the app after you’ve signed in you are greeted with an incredibly minimal experience — there is just enough information to convey what is needed and nothing more. From the top there is a settings button, your username and a share button. Smack dab in the middle is your unread message count spelled out and sitting at the bottom is your inbox bar. Tapping the inbox will bring you to well… Your inbox of course.
The background actually changes from a very nice blue to orangish-red when you get a message to reflect the OrangeRed style of Reddit. With this it’s really easy to know if you’ve read all of your messages or not. It’s subtle features like this that really lend themselves to the overall minimalistic design aesthetic that he has embraced with the development of this app.
By far my favorite feature is “classy mode” which is effectively a night mode theme. I always appreciate it when developers add a night or dark mode as it’s just so much easier on the eyes at night or some people just like the look of it better. The background still turns a slight bit orange so you can tell if there is an unread message just by glancing at the screen.
After everything is said and done there is very little left to be desired with this app. He nailed it on the head with the functionality and design of the user interface and there have been very little problems with the back-end cluster that runs the push notifications. When I was beta testing the app there were so little issues that I never had to give any bug reports and really only suggested some features and gave some praise on the subreddit he set up for the app.
It’s nice to see developers making their own subs like that to enable users to have a centralized place for feedback and questions, often getting help from other users or the developer himself. This really shows how much he cares about his product and the support and customer service thereof.
Thanks for reading and look forward to an interview from the developer coming in the next few days!
Ahead of the Apple Watch launch on Friday, Apple has published a new support page going over the Watches heart rate monitor. We know that the Apple Watch tracks your heart rate when you’re doing a workout and every periodically throughout the day. Using the Heart Rate Glance, the user can check their heart rate as many times as they please. The Watch is also capable of determining the amount of calories burned per day using intensity data recorded during workouts.
The support document notes that the Apple Watch will be recording your heart rate every 10 minutes. This data will be recorded in the in-house Health app for viewing this data at a later date and for third-party iPhone app support.
The Watch has incredible software features, but the hardware is just as great. Apple also has a diagram of how the Apple Watch should be worn for the best accuracy.
The function on the Watch isn’t perfect either. To get an accurate reading, Apple recommends having the Watch close to your skin. Obviously, other aspects of the human body can negatively effect the Watches reading of the heart rate, as Apple claims.
A fancy way of describing how much blood flows through your skin, skin perfusion varies significantly from person to person and can also be impacted by the environment. If you’re exercising in the cold, for example, the skin perfusion in your wrist may be too low for the heart rate sensor to get a reading. Motion is another factor. Rhythmic movements, such as running or cycling, give better results compared to irregular movements, like tennis or boxing.
Will you be able to reliably trust the Apple Watch reading your heart rate?