Save The Apps

I often see people, including my own father, close all of their iOS apps to save battery, but unfortunately this is usually not the best practice. Now, I will agree that if your battery is extremely low, killing background apps might buy you a few extra minutes, but in general it’s better (and easier) not to.

On iOS there are a select few types of apps that can actually run in the background for an extended period of time. Killing those can save your battery, but they are the exception. The types of apps that can run in the background are GPS apps like Waze, audio/airplay apps like Pandora, and VOIP apps like Skype. All other types of apps can only run in the background for about two minutes after you use them, and usually this process allows the app to perform any needed cleanup, finish downloading or uploading files, and enter a low memory state. Killing apps can actually hinder their performance and leave you with a worse user experience since the app has to completely boot up again, try and restore it’s state, and probably go to the Internet to get updated data. 

With iOS 7 Apple introduced a feature called Background Fetch. This feature allows apps that utilize it to wake up for very brief moments in the background and update their data and state. Apps performing background fetches only get about 30 seconds to do so, and iOS tries to optimize when these apps will wake up based on several factors including the device state and your usage patterns. If you are worried about this feature sucking down your battery you can disable it in your device settings on a per app basis. If you disable this feature for an app then it simply won’t be woken up by the system, but can still sit in a low memory state ready to quickly be re-opened. With apps like MailDeck, background fetch allows the app to get new emails so that when you open it they are downloaded and ready to be read. Otherwise, if you kill MailDeck and have a hundred new emails, when you open it has to go and download them all at once and while you are interacting with it, as opposed to a few at a time when your phone is idle.

When an app isn’t in the two minute background window and isn’t performing a background fetch it isn’t using up any of your battery, so why would you waste time shutting it down? Stop the killing and save the apps people…you too Dad. 

Singletons, You’re Doing It Wrong

There isn’t any one pattern fits all in programming, different designs are best for different situations. Unfortunately, the singleton pattern gets an especially bad rap from a lot of programmers.  Like all design patterns, the singleton can cause problems, but I believe this is largely due to mis-use and mis-understanding of the pattern.

The Good

Management and Memory:

Singletons are great to manage several operations or objects. Using them as the ‘Manager’ or ‘Controller’ for several objects makes them great to manage memory too. They can listen for memory warnings and quickly free some of their objects when needed. Let’s say you have an ImageCache object. Since it’s in-charge of all of your Image objects it can easily manage the memory around them. If the Image object itself was listening for memory warnings, how is it to know whether or not to free itself from memory? How would different owners of different Images know that they don’t need to clear their cache because other owners took care of it? The singleton makes the executive decision. It knows how many images it has in memory, which ones were accessed more recently, and how big each of them are. It’s the boss and central authority which can allow you to tune it to meet your needs and easily debug exactly what’s happening.

Similarly, since singletons can be in charge of several operations they are great for managing synchronization, concurrency, and performance. They can appropriately adjust order and timing and you can easily find that same central authority that is making all the decisions.

Portability and Re-Use:

A good singleton should be very portable, since chances are integration with your code base is spread pretty wide. With a portable singleton you now have an entire controller that can be ported to other code and very easily re-used.

Take a game with an EnemyManager singleton. If constructed properly, you should need maybe two classes and a header file to re-use it (we are assuming a fairly simple enemy here: Enemy, EnemyManager, GameConstants.h). Now, if you made EnemyManager relatively de-coupled, but didn’t make it a singleton, you could still probably port it easily. I would argue though that a singleton is easier to integrate, especially on a global scale. Also, if the singleton handles threading itself, then it’s another headache off your plate. It takes a minimal amount of effort to re-use a singleton in other projects.

Multi-Instance Singletons:

When you think of a singleton, you think of one instance, and though multiple instances technically aren’t a singleton by the definition, I would argue some classes that manage their own global state of one instance still qualify. Many classes that are ‘pseudo singletons’ can in fact have one global shared instance and several independent instances. This provides a lot of flexibility if you want to have a global variable or if you want to restrict its scope.

A good example of this is Apple’s NSUserDefaults class. NSUserDefaults has a +sharedDefaults method to access a global instance of itself, but if you need a separate instance you can create your own and pass it around.


Singleton’s make debugging a whole lot easier. If you’ve ever had a breakpoint in a class that has hundreds of instances you know the pain of trying to step through the code and figure out what object you are looking at. It usually requires modifying the code to create only one instance to step through it properly anyway. With a singleton you only have one instance, so when that breakpoint hits, you know exactly what you are looking at. Additionally, if you are trying to figure out when a property is read or modified, put a break point in the singleton and then you can easily monitor what is accessing it and from where. Lastly, with a singleton you can very easily modify states for debugging and have them take effect across the whole code base as well.

Easy Access:

One main advantage of a singleton is global access. If not done carefully, global access will corrupt your code base, but if you do it right it can make management so much easier.  Rather than having to pass an object around from class to class you can very easily access and modify its state by asking it for itself. Anywhere in your code you can ask the GameManager if it’s paused, rather than having to give everybody their own pointer to a GameManager.

The Bad

Lots of Mutability:

With great power comes great responsibility. A singleton with too much mutability can really make things messy quickly. You shouldn’t be modifying a singleton’s state too frequently, and certainly not in too many places. A good example is a login screen. When the user logs in you could set LoginManager’s currentUser, and then set it again when a log out occurs. While you will likely access currentUser in several places, you are only modifying its state in two places, and only after the user takes a specific action that will likely only occur once per session. A bad example would be an asynchronous NetworkController who’s network operations toggle a isWorking boolean on it. Since these operations have no knowledge of one another they shouldn’t be changing this state. Just because one network operation finished doesn’t mean others aren’t working.

Too Easy To Access:

Since singletons are really easy to access on a global scale it can be easy to muddy up your code base. You should be thoughtful when accessing or modifying a singleton’s state. Just because you have this great and easy to use tool doesn’t mean you can be careless with it. Modifying a singleton’s state carelessly will leave you extremely frustrated when you are trying to debug your code.


The delegate pattern doesn’t work well with singletons. In certain languages you can do some tricky things related to memory management and multiple delegates, but really what you are doing is adding observers. Having a single delegate doesn’t work with singleton’s because you will likely have multiple things setting it.


Singleton’s are inherently bad at scalability. Unless you create the ‘pseudo singleton’ I mentioned above, if you need multiple instances of your singleton you are stuck. The key is to avoid making things singletons if you believe you will likely need multiple instances.

Unit Tests:

While singletons are good for injecting test data, they can be frustrating with unit tests. Singletons can’t be broken into smaller scopes for unit testing, so all your unit tests affect one another, pretty much making any test useless.



There is this common myth that singletons create tightly coupled code. Guess what? Anytime you need to access a class from another class you are coupling those classes together, regardless if they are singletons or not. Now, of course, some will probably argue It’s easier to create a singleton with a lot of dependencies since it’s accessed across the code base, but I would actually say with a singleton it’s easier to avoid. Why you ask? If you know a class is a singleton then you know not to have it dependent on other classes (at least as much as possible), where as if it’s just another class it’s easier to overlook what dependencies you are putting into it.

A singleton with lots of dependencies is a bad singleton, and will create a lot of ugly and tightly coupled code. Singleton’s should be very loosely coupled to other classes internally so they are lightweight and portable. That way if you do have classes that touch your singleton, it’s very easy to bring it along with them for re-use.


Saying that singletons are bad for concurrency is a bunch of hogwash. They are in fact often really good approaches to managing multi-threaded processes. The argument goes that with singletons you are accessing the same space in memory across threads and you may get deadlocks and synchronization bugs as a result. This argument is naive. With any class you can get yourself into a world of trouble with concurrency, regardless if it’s a singleton.

Sure you can certainly have a singleton access shared memory across threads, but you can also synchronize that access with a singleton extremely easily. Additionally, you could duplicate the memory for a thread specific scope, and what better way to manage it than a singleton. This actually makes threading easier since your code can just call the singleton and it will handle the synchronization and/or concurrency automatically.


Well we can’t talk about singletons without talking about logging. Everyone jumps to this as the ‘ideal’ singleton and then the naysayers mention how their project has several loggers. A common argument that logging isn’t suitable for a singleton is that your log file or console can quickly become bloated and you cannot isolate logging to specific areas. Well as Captain O’Hagan from Super Troopers said best “[irish accent] I’ll believe ya when me shit turns purple and smells like rainbow sherbet.”  It’s very simple to have a singleton that has several different logging capabilities, be it by type, thread, or scope. In fact, if a singleton manages the various logging sectors it can also globally and easily manage whether or not they are enabled. Take these implementations in Objective-C as an example:

[[Logger sharedLogger] logEvent:(NSString *)event withType:(LogType)type]

[[[Logger sharedLogger] loggerWithID:(NSString *)loggerID] logEvent:(NSString *)event]

[[Logger loggerForThread] logEvent:(NSString *)event]

Very easily you can segment and control your logging while using one instance to achieve it and have global access across your code base.

Lazy Loading:

People often argue that lazy loading of singletons can create performance problems because you don’t know when the object will be instantiated. I have a couple of problems with this thought process. The first is that if you didn’t have a singleton, you would likely have to instantiate the class when you wanted to use it, and even though you know when it’s created, you are consuming unnecessary CPU cycles. In the right situations a singleton is more efficient because the creation only happens once.

The second problem I have is that if you want to know when a singleton will be created, ensure that your code is structured as such. Load the singleton at app launch or during a game loading screen. Lastly, why the hell is your singleton doing a bunch of heavy operations when it’s created? And If you really do need to do some heavy lifting why isn’t it asynchronous?

When to use a singleton?

It is important to ask yourself a few key questions when deciding whether or not a singleton pattern is the right one.

  1. Is your class suited to (generally) have only one instance?
  2. Does your class need to be shared across your code heavily?
  3. Does your class need to control several objects and/or processes?
  4. Does your class require synchronization? (Such as writing to a database)
  5. Is your class fairly immutable? Will you being modifying its state minimally?

If you answered yes to most of these, a singleton may be the right choice for your class.

A few good examples of singletons are:

NetworkController – Easy to manage multiple asynchronous network requests and allows any class to quickly integrate with networking.

LocalStore – Most databases need synchronization when writing and reading. Having a single instance to manage your single store makes this a breeze.

ImageCache – As I mentioned above, having one instance managing your entire image memory footprint prevents duplicates and allows for better optimization.

LoadingIndicator – For iOS I like to use a pattern of showInView: and hideFromView:. This allows multiple loading indicators to co-exist based on their view, but integration to show a loading indicator is minimal since they are managed by the singleton.

GameManager / Application – Chances are you have your game or app. Chances are there is only one of them. Chances are it will run itself once within its own scope. A singleton is perfect to manage this since the one instance of your code should be managed by one instance.

ConfigController – You may have multiple configurations that need loading depending on what you are doing. For simple apps though, a single ConfigController usually suffices, and then your code can ask it for configurable states easily. Additionally, you can easily modify this state for debugging.

AdController – Again, different circumstances may require different designs here. But if your app is just showing some simple ads, chances are you want to get them from one manager.

Analytics – In general Analytics are used to track user sessions. Since there is likely only one user, on one device, in one instance of your code, having a singleton for analytics makes perfect sense. Additionally, analytics usually write to a store and use networking, with a singleton you can ensure this process all happens under one roof.

PurchaseManager – Items are either purchased or they aren’t. Having a singleton purchase manager can easily allow different parts of your code to check the purchased state. Also, a user probably isn’t purchasing things too quickly so modifying state should be minimal.

ConnectivityController – A device is either connected to the internet or it isn’t. No reason to have multiple controllers checking the same state. With a singleton monitoring connectivity, your entire code base can quickly check its status.

VersionController – Your product has a version. When running, just one version is running. A singleton that can both check for updates and give global access to the version is handy. You only need one of them and they are immutable, perfect for a singleton.


I’ve written a lot of software, with a lot of it doing very different things. Without even looking at my previous projects I can pretty much guarantee every single one of them has at least one singleton class. The singleton is a great design pattern when used properly, and no matter how many programmers dance to the tune of “singletons are evil”, I will continue to use them and advocate for them. I’ve searched high and low, have had debate after debate, but am still waiting for someone to convince me singletons should be avoided.

Use MailDeck to tame the email Beast.

We Hate Innovation – Follow Up

After posting about how we hate innovation, a reader brought Jitneys to my attention. Jitneys were unlicensed taxis in the early 1900’s, and most cities made moves to shut them down. So Uber’s core concept isn’t necessarily innovative. I would argue, however, that their model of using phones and GPS, and even vetting their driver’s is. Jitneys had pretty much no regulation around them, where as Uber at least has requirements of their vehicles and drivers.

Another interesting thing pointed out by a reader was the steam industry. Steam was over taken by combustion engines and eventually died, a perfect example I should have included in my post. An interesting fact I found when doing more research was that laws actually helped kill the steam industry, where as laws today are preventing new industries from overtaking existing ones.

We Hate Innovation


Not too long ago society welcomed innovation; it generally improved our quality of life. Unfortunately in the year 2014 we snub our noses at innovation in favor of archaic, familiar, and embedded systems.

Don’t believe me? Look at companies like Uber or Tesla. Uber is being blocked all over the world by cities and cab companies simply because it’s competing. What happened to a free market where the company that can offer the best service at the right price wins? Uber cars are generally nicer than cabs, in my experience the drivers tend to be as well, and they are cheaper. Not to mention an Uber driver won’t drive away with a stranger, where as a cab will take the first fare in their backseat. I also don’t have to fumble with payment in an Uber like a cab. So the Uber experience is much more pleasant, faster, and cheaper but we want to block it?

It’s obvious who doesn’t want services like Uber to succeed and thats the cab companies and the cities who collect revenue from them. Now, I’m all for cities generating revenue in order to make life for their citizens better, more sustainable, and ordered. I’m not, however, for cities putting revenue above the well being of their citizens. After all doesn’t more cars for hire in a city free up parking, reduce drunk driving, and encourage carpooling? All things a city and it’s citizens generally promote already? Austin, Texas has laws that require private cars cost a minimum of $55 and that you have to wait 30 mins before being picked up. In what world is it beneficial to the citizen to have to pay more and wait longer? The city ordinance literally requires both a driver and a rider to waste 30 mins before going anywhere, please tell me how this makes sense?

Tesla is a very similar story with many states banning them being sold for fear of car dealerships going out of business.Tesla sells directly to the consumer, cutting out what some what call the ‘shady’ middlemen. Certainly makes sense to buy a Tesla from Tesla, yet lobbyists and politicians have decided this is bad.

What about the cab companies and car dealerships you say? Well they could make their service not terrible and actually try to compete with Uber and Tesla. Yes cab companies have to pay for a permit from the city, so they may not be able to beat the price, but why should we prevent an outdated business from dying?  Should we keep buying CD’s so record stores stay in business?  Adapt or die, that’s business and that’s life. Industries may have longer lives than some humans, but they are all finite.

Software, which could be argued as one of the most innovative and fast moving industries right now, is also quickly being blocked as well. Companies are creating walled-gardens in order to develop for their systems which make them the final decider on whether or not someone can innovate. Shouldn’t it be up to the user what kind of software or apps they want to put on their computer or phone? What kind of video games they want to play on their consoles?

How is anyone going to change the world if no one will let them?

While we are stuck innovating within Apple’s guidelines with MailDeck, we will continue to do our best to push those limits. We will do everything we can to change email and continue to bring our customers great and innovative features. The world may hate innovation, but that isn’t going to stop the rebels, dreamers, and artists, and it certainly isn’t going to stop us at MailDeck either.

11 Lessons From The Startup Graveyard


Conservatively, 75% of all startups fail. Some analysts put the figure as high as 90%.

A humbling statistic when thinking about starting your own business; A frightening one when already in the process. The thing is though, it’s just that: a statistic. If you really want to be chilled to the bone head on over to also know as the “Startup Graveyard”. You can view the countless posts from all the real startups that didn’t make it. Entrepreneurs writing heartfelt obituaries for their companies they worked so hard to build. Many express where they went wrong, and what they’ve learned along the way.

One glance at /r/shutdown and all of the sudden a simple statistic becomes very real. It puts faces on the ‘victims’, and cuts right through the optimistic vision many entrepreneurs share for their business or idea. Being optimistic about your idea is essential, it drives the passion that allows you to make it a reality. With that said, we all get overly optimistic from time to time, and can make mistakes as a result. Being humbled by the reality that you are not invincible or perfect is a necessity for level-headed decision making. When my ego begins to get away from me, I try and remember one thing:

“Only a fool thinks they have nothing left to learn”

With that motto in mind I’ve read through failure story after failure story in the Startup Graveyard. I’ve tried to learn what I can from those that have failed before me so I can do my best to avoid the same mistakes.

I’ve compiled 11 common shortcomings that led to the demise of so many startups:

1) Listening to users, trying to make everyone happy

User feedback is important, but remember to take it with a large grain of salt. Trying to meet too many customers needs can quickly degrade your vision and ultimately end up costing you your business.

2) Basing your business on an API or Third Party service

If you are looking for extremely rapid validation then using an API or other Third Party service isn’t a terrible idea, but building a long term business model around it is. Being dependent on third parties creates an extra potential failure point. if your business is based entirely around someone else’s tech, they could easily shut you down tomorrow.

3) Staying rigid, not validating value propositions

The buzzword “Pivot” might be used a little too often when referring to startups, but it is essential to be ready to adjust your business model if your initial concept or idea isn’t gaining the traction you require. The key is to pivot early and to test the waters with user feedback, conversion, and retention. Pivoting too late can result in running out of time or money and ultimately kill your business. It is essential to identify problems early on, and back up your decision making with data.

4) Losing focus

While it is important to pivot when you identify a problem, you need to make sure you remain focused. Pivoting too often or jumping from idea to idea can leave you with a tangled mess of unfinished concepts. It is important, once you do have your idea validated, to remain vigilant and see it through.

5) Greed 

Many founders lose their business because they don’t want to give away too much equity to raise capital. While you need to be vigilant with your equity, being too greedy with it can prevent you from raising the funds you need and ultimately kill your business. Remember that a small portion of a big pie is better than no pie at all.

6) Lack of production

This one is simple. If you don’t produce anything it’s pretty tough to acquire users and or customers. Many times people have great ideas but fail in the execution. Behind validating your idea, I might argue building it is the next most important thing.

7) Founder conflicts

Founder conflicts are the norm in the startup world, and it’s unfortunate. One way to help avoid conflicts between founders is to clearly define founder roles. This prevents  the “you were suppose to handle it” argument. It also allows you to part ways with founders that aren’t fulfilling their roles more easily.

8) If you build it they will come mentality

Marketing is essential. While ideas sometimes do go viral with very little marketing, it’s not a regular occurrence. Remember people do win the lottery occasionally too, but the odds aren’t very good. Depending on luck is a surefire way to fail. You need to have a solid marketing strategy and make sure you execute it. Don’t forget to budget for marketing either.

9) Ignoring data and not running the numbers

Do the math – cost of acquisition vs. average return per user, conversion rates, active users, age and location demographics. These are just a few stats but it’s important to pay attention to analytics so that when you make changes you can effectively track them and make sure they are creating growth. It’s essential to use your data to target the right markets and make the right decisions.

10) Micromanaging 

When your business is your baby you can be extremely protective and overbearing. Don’t do this. While it is important to keep an eye on things, micromanaging will almost certainly slow things down, and will likely create unnecessary conflicts. Hire the right people that you trust so you don’t have to look over their shoulder constantly.

11) Not swallowing your pride and asking for help.

People are often afraid to ask for help. Don’t be. Asking for help can not only give you valuable insights, but it can lead to great opportunities. After all, asking for funding is asking for help. A recent study by Harvard Business School even found that asking questions can make you seem smarter and more competent.


Thankfully my startup, MailDeck, has not yet failed; hopefully it never does. Every day I remind myself that it might though. That grim daily reminder keeps me motivated and driven to prevent MailDeck’s final trip to the Startup Graveyard like so many before it.

You can do everything right for your business and still have it fail. The market doesn’t always accept new ideas, and sometimes timing just isn’t right. However, there’s no excuse for making avoidable mistakes due to lack of research. The fact that you are reading this means you are already seeking out advice to avoid failure. Continue to do so and you will greatly increase your chances of success. Just remember, the moment you think you are the smartest person in the room, you no longer are.

App Store Woes Part Two

While I waited two weeks for MailDeck to get approved by Apple with iOS 8 fixes, I wrote a post about how broken the App Store is and some changes that are needed here.

I’m happy to say that our update was finally approved after two expedited requests and 15 days of review time. Unfortunately, the second we went live we discovered that iOS 8 devices were not getting push notifications. Turns out we had a bug in our code. It was a simple one line fix, and we submitted an update to address the issue immediately.

So what’s the problem?

Since we just used two expedited requests (one after 15 days mind you, so hard to call them “expedited”) we can’t submit another one to get our fix live in the store. So now we are stuck hoping for a quick review time and fielding customer complaints while our fixed version just sits there.

Our customers could face not getting push notifications notifying them of new email for up to two weeks at Apple’s current review rate. It’s absolutely ridiculous that a simple one line change to our app binary now requires an entirely new “review”. I put review in quotes, because there won’t be a real review. We will land on someone’s desk and go live a few moments after that. We are essentially waiting for someone at Apple to read our note saying the update fixes a push notification bug and nothing more.

To my customers I am sorry. I should have caught this bug before it went live. Unfortunately, we all make mistakes.  The fix took a matter of minutes, and in our always connected world, you would think it could be on customer’s devices shortly after that. Sadly, we have to wait in a very long line for our case to be heard.

Apple’s Broken App Store Review Process

appstorebrokenWhen Apple first opened up the App Store in 2008 it was the wild west. Sadly, even today with billions generated in revenue and over 1.4 million apps, many issues still remain.

Before I get to the issues, I want to start by laying out my own credentials when it comes to app submissions. I got in the iPhone game right at the start and to date have had over 25 apps live in the App Store. Some of these apps also saw quite a few updates, so conservatively I’m probably nearing around 100 app submissions. I’ve submitted apps for all categories, have had many featured by Apple, and have even reached the #1 spot overall. At the time of writing this, my latest app MailDeck is featured as the #1 Best New Productivity app in the United States. I’ve also had a few app rejections; some warranted, and others for absolutely ridiculous reasons. The point being that I’m quite familiar with the process…and unfortunately its pitfalls as well.

So what are the pitfalls?  

One major issue is the arbitrary and inconsistent rejections. Thankfully, Apple has gotten a lot better at this in recent years, but their logic can still leave you scratching your head from time to time. More than once I have seen an app rejected, only to be re-submitted with absolutely no changes and then accepted. Or similarly, two apps submitted at the exact same time, both violating the same restriction, and yet one makes it through and the other does not. I’ve even seen an app rejected citing a specific guideline that has absolutely nothing to do with the rejection. If Apple can’t find a rule but still doesn’t want to let an app through it seems they just close their eyes and point. I can only assume all of this is due to the human element, and that it is likely different reviewers are looking at the apps.

But that brings me to my next issue, and that’s the lack of transparency. The review process is a big black box with a single light on top. You put your app in it and have no idea what goes on inside. You sit and wait for the light to turn on and go yellow. Then you wait for an undetermined amount of time to see if the light will go green or red. Green you’re good to go, red it’s back to the drawing board. Sometimes you can hit the box with a hammer and it seems to speed up the process, but you’re never really sure, and you feel bad for the dents you put in it.

That sounds so pathetic that you would hope I’m exaggerating or kidding, and I wish I was. You upload your app and wait for it to go into a “Waiting for Review” state. Then at some point the app will progress to a “In Review” state, and then at some point after that it will either be rejected or accepted. The hammer? Well that’s the expedited review process, and while it does work sometimes, Apple makes sure to shame you for using it and not following the rules like everyone else.

So how long do you have to wait you ask? The answer is you have absolutely no idea.

Bringing me to my third issue, which is a complete lack of review time estimates or even your position in the review queue. I’ve had an app “In Review” for 10 minutes, and then an update to the exact same app that simply fixed bugs be “In Review” for days. I’ve had an app approved in 1 day from start to finish, and I’ve had an app take over 3 weeks. This is a pretty awful experience when you are trying to coordinate with your customers, marketing team, investors and/or clients. There are third parties who try to monitor twitter for average app store submission times, and while this is better than nothing, it unfortunately doesn’t always give a very accurate picture (especially because it’s historical, unconfirmed, data). It would be nice if Apple officially tracked and posted this.

Which brings me to my fourth and final point, and that’s the lack of communication between app developers and the people running the walled garden that is the App Store. I had an app name expire because we decided to add a tagline and decided we weren’t going to use the base name by itself. Unfortunately, a year later, we changed our minds and wanted to drop the tagline all together. Since the base name expired we couldn’t automatically do this and had to reach out to Apple. It took over 2 months, and talking with more than 5 people at Apple, to simply drop the tagline off our app name and use our trademark. Apple put the expiration in place to prevent name squatters, but it seems they just don’t really care either way. You can call iTunesConnect support, but you will never actually talk to an app reviewer. They do occasionally communicate with email, but unless you have special connections in Apple, getting anyone’s ear can be near impossible.

The Fix?

I am writing this post for one reason, and that reason is for change. This is not meant to be an angry or hateful post. It is meant to give a view into a world that few people but developers know. Hundreds of millions of dollars are invested in mobile apps, and many businesses have an app as their one and only product. Building a business around a mysterious black box doesn’t leave anyone feeling comfortable. Additionally, being unable to get critical updates out to users to address their issues doesn’t make anyone happy. A better App Store process for developers means better apps, happier consumers, and more revenue for Apple. It’s a win win for everyone.

Here are a few simple steps I wish Apple would take to solve some of the problems I pointed out:

1) Hire more reviewers – Apple has $150 billion in cash. Please Apple use a fraction of this to hire more reviewers. Several days to weeks for simple updates to go through is unacceptable. There is no reason for these delays in the modern world of instant, digital distribution.

2) Let us see in the black box – Open up the inner workings of the App Store approval process. Why is this a secret? Let us see what goes on inside, let us know there are human beings tapping on our apps and making these judgment calls. Are there review boards? Does only one reviewer look at each submission? Do the same reviewers stay in a particular category such as Games or Productivity? Do reviewers work nights and weekends, are they even in the U.S.? (I’ve seen apps approved all times of day and on weekends as well)

3) Have an official estimate and position in line – You approved all apps within a 5-7 day timeline this week? Great then publicly tell people that the average review time is 6 days. Additionally why won’t you show me how many apps are in front of me? At least then I can keep checking progress as we move through the line.

4) Give developers account managers – I’ve heard some developers do have contacts in Apple to help manage their accounts. Unfortunately, it seems to be a special privilege. Give me someone who is familiar with my app and that I can communicate with when needed, instead of having a different person respond to me every time and have to be familiarized with our app and company all over again. At least pretend to care about developer relations, we do give you 30% of our hard work after all.

With a company the size of Apple, I don’t really think I’m asking too much. Some simple tweaks will make a lot of developers lives less stressful. We all want the same thing, and that’s great apps on great devices. Lets work together to achieve that.

If you are an iOS developer please share your stories in the comments, I have no doubt you have some.


Note: MailDeck 2.5 which fixes iOS 8 issues is still “In Review”. We were rejected last week for a full screen sharing extension. Apple cited the following rules, and seeing how our app has nothing to do with a Keyboard you can definitely ignore 25.4 – 25.8.

25. Extensions
25.1 Apps hosting extensions must comply with the App Extension Programming Guide
25.2 Apps hosting extensions must provide some functionality (help screens, additional settings) or they will be rejected
25.3 Apps hosting extensions that include marketing, advertising, or in-app purchases in their extension view will be rejected
25.4 Keyboard extensions must provide a method for progressing to the next keyboard
25.5 Keyboard extensions must remain functional with no network access or they will be rejected
25.6 Keyboard extensions must provide Number and Decimal keyboard types as described in the App Extension Programming Guide or they will be rejected
25.7 Apps offering Keyboard extensions must have a primary category of Utilities and a privacy policy or they will be rejected
25.8 Apps offering Keyboard extensions may only collect user activity to enhance the functionality of their keyboard extension on the iOS device or they may be rejected

I certainly fail to see any mention of full screen extensions being restricted, and ironically enough the default Mail app is a full screen extension. We have tweaked the app and submitted an expedited request as well as called support. We understand an email app that functions and works is essential, and we have conveyed this to Apple over and over. We are on the front page of productivity and can’t get our update through to help all of our customers upgrading to iOS 8. We are hoping it goes live very soon, and are sorry for the inconvenience. If you just read this post, you can see it’s not entirely under our control.


Quick Photoshop – Cell Shaded Loading Indicator

I wanted to enhance my photoshop skills, but as usual work has consumed all my time

A little while ago I did have some time, so I made this cell shaded loading indicator. I didn’t post it because I think it’s just ok. I also later noticed that the dashed circle isn’t symmetrical and it drives me crazy. I’m posting it now to motivate me to find some time to use photoshop and keep playing around to improve my ‘skills’.