Last night, Apple rejected a new app that I had submitted to the iMessage App Store. I am not writing this to complain about the rejection¹, but to talk about how it could have been avoided.

---

The app was pretty simple; it let you use Apple’s emoji as stickers in iMessage. It did this by creating an image for each emoji at runtime by calling draw(at: withAttributes) on an NSString that contains the emoji. I then made that image available as a MSSticker.

Before I even started writing the app, I knew that there was a chance that I was going to get rejected for using Apple’s emoji (even if I was not actually including images of the emoji in the app binary).

Even though I knew I was working in a potentially gray area, I decided to go ahead and write the app. The risk was pretty low because I know I could get the app finished in just a few days. Plus, I just wanted the app to exist; I liked the idea of being able to use the entire emoji set as stickers.

So all things considered, the potential reward of having the app and maybe making a little bit of money² was worth the risk of a couple of evenings worth of development.

---

The problem here is with apps that are larger scale. If I came up with a larger scale app idea that lives in the App Store approval gray area, I probably would just not write it.

I think that Apple needs to have some feedback mechanism in place where developers can ask questions and get clear answers about the legality of a particular app concept before they spend months building it.

This exchange would have saved me two weeks of work that could have been spent working on other app ideas:

“Can I build an app that lets me use Apple emoji as stickers in iMessage?”

“No.”

There are plenty of more substantial examples that took more than two weeks of work:
– Can I build an app launcher in a Widget?
– Can I build a calculator into a Widget?
– Can I send files from my FTP server to iCloud?

A system like this would benefit both Apple and developers. Developers would be able to proceed at building an app with confidence or be able to spend their time on something that could get approved.

Apple would be able to see how developers wanted to use certain APIs months earlier. If they are asked something about a use case that they never considered, they can decide earlier whether or not that use case should be allow (and if appropriate, update the App Store guidelines accordingly). This would be especially useful during the summers when developers are building new apps and features using APIs that are still in beta.

To be clear, I am not proposing any type of pre-approval of apps – apps should still be thoroughly checked to see if they follow all of the rules. There just needs to be an official way to find out if something fits within those rules without having to build and entire app and submit it to the App Store³.

---

A couple of years ago, I would have said that a change like this would never happen. However, the App Store has seen significant improvements over the last year since Phil Schiller has taken over. Under his leadership, the App Store has seen big changes that benefit both developers and customers. After seeing all of the recent App Store changes, I would not be surprised to see a system like this implemented.

In the meantime, I am able to satisfy my goal of using Apple’s emoji in my iMessage conversations, even if my friends can not use them to respond back 🙃.

---

Update: Just to be completely clear, I am not complaining about my app getting rejected. I am 100% okay with that.

I am just using my rejection as an example for how the App Store approval process could be improved by adding more clarity and transparency for what is allowed and what is not.