Other than big changes in how the app navigation was implemented (the current single scrollable view vs. the previous one with multiple independent views; I also tried different input modes based on the orientation of the remote), 1.0 did not gain new features compared to that initial AppLovin prototype. The prototype even had a preview of something that had to wait for the first update: As tvOS does not support EventKit and has therefor no access to calendar data, I developed a companion app for iOS that would allow to export phone/tablet calendars and sync them via iCloud. I waited with this feature mainly to see if the app itself would pass the app review process, after which I felt free to increase the complexity.
Update 1.2 became a bigger piece of work. Intended to only add a reminder to the Top Shelf items, I discovered that the memory problems I was able to circumnavigate before, reappeared with the tvOS 10.2 beta. While waiting for Apple to answer my question whether this could be a problem only observable with the beta, I started working on the next feature: custom images. As with the calendar sync or the new reminder feature, the companion app plays a major role for custom images. While it is possible to access the iCloud photo library from Apple TV, choosing and cropping images so that they fit the calendar format is much easier on iOS devices. So that’s where you can now select up to 12 images of your own.
As for the memory problem: I had to wait until the official release of 10.2 to find out that yes, extensions now seem to have less memory available to them. So for version 1.1 this meant that the Top Shelf extension would run into memory errors, resulting in everything resetting after the first item was generated. So the weather forecast and quote of the day item would never appear. I had been working on fixing this bug ever since I contacted Apple about it, but it still took me more than a week after 10.2 went public to finally fix it. Hope I did not loose too many users because of this.. Will have to see how 11.0 turns out in this regard.

As I was one of the fortunate to win an Apple TV developer kit, I started working on ideas all the way back in September of 2015. As everybody was criticizing the text input (and as I can't help myself), I immediately tried to think of alternative keyboard designs. But as keyboard extensions were/are not allowed, I needed an app to implement the keyboard in. For some un-remembered reasons, I ended up choosing to develop a calendar app.
And while I had a working concept, once Apple implemented dictation and updated the iOS Remote app, it felt like too much hassle to force an alternative input method on the users.
At the same time, I became quite interested in the Top Shelf feature and explored what could be done in that space.
My basic concept was to create a TV pendant of classic wall calendars usually hung at home or in the office, but instead with some dynamic elements and - of course - living on the Top Shelf.
The Apple TV Tech Talk in January of 2016 could not have been timed better (or located more conveniently right here in Berlin). I had a problem when trying to update Top Shelf items and one of the engineers on site could point me in the right direction.
Next big milestone was the AppLovin Apple TV App Challenge or rather finishing a prototype to participate in it. Some troubles with the memory limitations of tvOS extensions made hitting the deadline of March 31st a challenge of its own, but I was able deliver a first version. While I did not win, having a deadline to get to a working state was quite helpful.
That initial prototype version still had to hibernate for some time, though, as I became a father on April 19th, reducing the time for spare-time projects to.. well.. zero.
1.0 hit the App Store February 20th, 2017. Here the initial (and current) app preview video

My initial driver to develop an iPad keyboard was to allow users to not have to look at the keys in search for the next letter. Thus, the eight button design was born. One button for each pinky, pointer, ring and middle finger. With that design, the user is supposed to place each finger above the buttons once and then just tap with the one/ones corresponding to the current letter. While it works fine, holding the hands still or getting them into the correct position to be able to hit the buttons can be challenging. So I kept looking for a better way to achieve my goal. During a WWDC presentation, a blind Apple engineer demonstrated some accessibility features and while I watched him orient his fingers on the iPad he was using I realised that this needed to be my goal: The keyboard should be designed with blind people in mind.
So with ‘Zwei’, I reduced the number of buttons to two (Zwei is the German word for 2), each spanning half of the screen’s width. Based on the number of fingers used to press one of these buttons, the user is presented with 5 characters. The first gets entered by simply releasing the button. Each of the remaining can be selected through a swipe gesture (up, down, left or right). In addition, while pressing the first button, the second button offers two functions that can be activated by tapping it with either one or two fingers. Examples for these functions are changing the input mode to upper chase letters, to delete the last character or the obligatory switching to the next keyboard.
Again, I think the app preview video will explain it much better

When the accessibility feature “Voice Over” is activated, the two buttons increase their height to half the screen as well. Characters are read out once selected and a confirmation sound is played when the character is chosen. I implemented this in contrast to the standard settings which announces the letter twice: once the button is touched and once the current button is released.

As you can see on the App Store, 'Shift' was actually published after the keyboard I will write about next. At the time, the other concept was just much more compelling to me, so I put this project on hold for a bit. As I started working on it beforehand, though, this order shall reflect that fact.
The concept behind 'Ahto' was to use up to three fingers in parallel on an eight button keyboard to enter specific characters.
For 'Shift', I kept the eight buttons (one for each pinky, pointer, ring and middle finger) but decided to give each one a modifier role. So if the user holds down on one button, the other seven get assigned specific characters based on that first button. The user can either release the first finger or tap one of the remaining buttons, each of which will enter a character (or perform a function). I designed the keyboard so that the one finger "tap and release" leads to common letters like 'a', 'e' or 'i' while entering e.g. the letter 'l' requires to hold down the forth button from the left and then tap the second  one from the right. I think a preview video might be good at this point

As for the name:
​I thought 'Shift' would be a good one as the shift key is the most commonly used modifier key. Everybody knows how it works and I hope it helps to get across the general idea. What I did not check in advance was whether there were any other apps with that name, much less keyboard extensions. Which - of course - there are. For a long time, there was a controversy regarding how Apple implemented the shift function. Some developers took it to themselves to provide alternatives and named their apps accordingly. So far, I stayed with my initial choice. But what to you think, is 'Alt' a better fit?
What also made the name a rushed decision was the easy path to the current icon

Visual design still not being my strong suit, I was desperately looking for something to use for the icon. With 'Shift' as the name, there was an easy answer, so I just went with it.

What motivated me to get back to this keyboard after I initially stopped working on it was the fact that the modifier concept allowed me to use 8 * 8 key combinations. As you can see, I used this for some bigrams i.e. two letter sequences that are common for the chosen language. Using 'Shift' for letters other than the 6 "direct tap" ones involves two buttons. The bigrams help to decrease the "taps per letter" ration below two.

As it turns out "having a blog" is not motivation enough to actually publish something. At least not for me. While I have been working on projects I could have written about here, I tend to get lost in the development process (which I love) and ignore doing something about the outreach (which is just not my forte). It is not that I ignore this completely. I start formulating texts that float around in my head. But that is usually where they stay.
So let me do some catch up, now, and try to get out stuff closer to the related work, in the future.
I just checked, the last entry is from August of 2015.
Other than becoming a father since then, I also published some.. keyboards, of course. Two to be exact. I also dabbled in some tvOS development.
Swift is still my language of choice. My only choice really as I am still not fluent in Objective C but want to stay in the Apple ecosystem.​