So as you may have heard, the latest update to Nintype (unfortunately, it's the one with all the good stuff - stability fixes / improved autospace / emoji / better options), has been rejected.

One of the rejection reasons was that the options menu was on the keyboard, rather than on the containing app (i.e the nintype notes app).

They also listed some of the preview screenshots featuring 3rd party apps (I'm guessing they mean the iOS notes app) as another rejection reason. I've removed those screenshots for now (somehow they survived the first two versions of the app).

Mandatory open access??

But this post here is about open access. Apple said in the rejection notice that settings should go in the containing app (i.e Nintype notes). For nintype notes to talk with the keyboard, it requires open access. This effectively means that nintype will require open access by default.

Some people thought it may be a good thing for Nintype to require open access. I am here to dispel that myth.

Advantages of Mandatory Open Access / Settings on Nintype App

1. Sounds? Last time I tried getting sounds to work, it lagged. Requiring open access for sounds is a silly thing in the first place, what does open access have to do with sounds?

2. Stability? The options page requires very little memory - the only reason it may sometimes crash is the same reason why it sometimes crashes when you pull up the calculator - surface area gets too big and because Nintype uses OpenGL, the OpenGL buffer pushed it out beyond the allocated memory limit. The jetslammed / jetsam fix the other day would fix these kinds of issues. The actual settings page has nothing to do with stability.

There's just no advantage for requiring open access, at all. Let's move to disadvantages

Disadvantages of Mandatory Open Access / Settings on Nintype App

1. The user has to go through this scary dialog box before enabling it. Users have left 1 star rating on the app because of this. You may not care, but some users care, and I care because of these users.

2. I have to spend time working on synchronization between the app and the keyboard. This complicates development, as now data has to be transferred and synchronized between different processes. This will mean more bugs, more time that I could have spent doing other more productive fixes/features.

3. There's three kinds of data storage. App data storage, keyboard data storage, and in-between data storage (called App groups). The only one both the keyboard and the app can access is the App Group storage, and this only opens up when open access is enabled. This means I have to make code that juggles save data between the keyboard and the in-between data storage when the user finally enables open access.

4. I'd imagine app review will be much more strict with keyboards that require open access. They're already giving me enough hard time as it is right now, but looking at their guideline it looks like this means there are extra guidelines I have to follow in this case.

Conclusion

I will implement open access later for extra features like backup and the like, but not like this. Mandatory open access is not the way to go.

Right now I resubmitted with none of those offending screenshots and will file an appeal shortly.

If this doesn't work.. then I'll think about it later.