Into the App Store in One Week
Then back to the Reform Club, or else £20,000 will belong to you!
Most of our work at Dubit is as an agency, so our schedules are very rarely our own. Sometimes we can buy a few days by getting our projects shipped ahead of time, which allows us to invest in our own process and skills.
That happened recently, and gave us a brief window of opportunity to test a theory — you can build a test-ready prototype in one week. The idea is that you design directly to your software, with a single hypothesis or previous results in mind, so that you can test your build then iterate.
You may know, that a week is generally the shortest recommended length for a sprint in Scrum. I would typically plan for fortnightly sprints, so this is a little tighter than I’m used to. To add on a little more pressure, I don’t have quite a full week, or a full team.
The Scenario
I have nearly one developer. One paid project has just finished, so maintenance on it is still a priority. It’s likely to cost me around 20% of my developer’s week.
We have no visual designer! They’re all busy full-time projects. Ditto for sound design. And for game design too, though that’s not a worry for such a small amount of work — testing and devs’ own abilities should be able to put a basic project together.
A senior developer pledged some of his personal time if needed, and I can do the same with my time to manage the project and pretend to be some of the missing roles from above!
I also lost some of the week because I wasn’t quite ready when my dev was, but I’ll elaborate more on that below.
The challenge we set ourselves was to build a working app with a game, in AR Kit, within a single working week, then push to Apple in the hope of getting it through App Store review over the weekend. App Store review can be a bit of a gamble, but we’re experienced in it, and the review times actually come down a little in December, as Apple tries to clear its backlog before they break for Christmas.
The Development
Our players are Alex as developer, Stefan as Senior developer, and me as manager and whatever remains.
Monday
Alex had just come off a project, having successfully shipped it, and had been put onto a training exercise by Stefan. A lot of AR and VR apps are coming into the studio, so it made sense to get some more ARKit knowledge onto our team.
At this point, we hadn’t yet committed to our one week challenge. I was out of the office until fairly late in the day, at which point Alex had a pretty impressive demo put together. We had an first-person shooter created in SpriteKit, which allowed me to wander around the office hunting and destroying aliens.
We discuss the idea of making a Christmas app each year, in the hope we have opportunity to make it happen. For several months at this point, people had been talking about making this years’ in ARKit.
This is when I floated the idea of making an app in a week. The Friday following was the last opportunity I felt there would be to get an app in the App Store before Christmas.
Tuesday
At this moment we’d committed ourselves to the project, and had started discussing what the app will be. There are some constraints, so that largely lead our design.
- We didn’t want to throw away what we’ve got — it’s hard enough getting finished in a week without starting again part way through.
- We didn’t want to release a shooting game — it’s a fine test internally, because it involves a lot of fundamental 3D games programming, but at Dubit we usually make games for young children. Guns aren’t appropriate.
- We wanted to make it Christmas themed.
We decided to make the game, throwing carrots to Santa’s reindeer. It’s largely just a graphical change from what we already had, with some adjustments to the way our projectiles and aliens (now Santa) moved. We also had some ideas about extending the game with some sort of score and a mechanic around reloading carrots, but time and priority would dictate that.
Most of that day would be spent fixing bugs in the demo we already had, playing with the way items moved in 3D space, and accepting that SpriteKit wasn’t going to be suitable!
SpriteKit allows you to easily place billboards in 3D space. Billboards are two dimensional, so always appear to face the user. We couldn’t understand what was happening in the scene because we didn’t feel like we could get under or around our quarry.
The solution for this is to use SceneKit, which allows 3D models.
Wednesday
Two difficult things needed to be done — convert the game to SceneKit, and source the 3D models. Using SceneKit is all on Alex, and it was solved by the end of the day.
Getting models is a little harder. None of us are 3D artists, and it’s not really something you can blag! I could get us so far with off-the-shelf models, but they didn’t come in the format we needed, and we were still short by a carrot and some presents. There’s no avoiding it at this point — I needed to beg, steal, and borrow 3D artist time from another producer!
I didn’t need much — they’re all fairly simple objects — but without the benefit of working in a studio, our project would have been blocked at that point. Assets in hand though, we were able to continue.
Thursday
One difficult thing needed to be done — fix everything.
Wednesday touched every part of the code, and now no part of it felt solid. We were starting to struggle getting everything positioned and scaled correctly, and that was blocking working on the gameplay.
This is the point which we needed a little senior dev input from Stefan. By the end of a long day we had the entire scene behaving (as long as everything in it was a present) and a list of 3D assets which needed adjusting and re-exporting differently.
Tomorrow I would have to barter for some more 3D artist time. I don’t know how anyone would get this sort of thing done without every type of resource under one roof.
Friday
Crunch time. Release day. Most of the programming work left would normally be finished more than an entire sprint before releasing a project. We can’t come this close without pushing it out though!
We managed to design, source, and program all the user interface and the audio in one day. While that was being programmed and packaged, I was able to put splash screen, icons et al together.
We pushed to Testflight and for App Store review at 1720 — ten minutes before the end of the Friday work day. Now we just had to see if Apple could review it before Monday, so we could have our App out within a week.
Saturday
I woke up on Saturday morning to an email from Apple telling us our App had passed review!
We had a whole day to spare.
“Tomorrow is Sunday!”
“Monday,” replied Mr. Fogg.
“No; today is Saturday.”
“Saturday? Impossible!”
“Yes, yes, yes, yes!” cried Passepartout. “You have made a mistake of one day! We arrived twenty-four hours ahead of time”
The Game
We show it to people who are interested, but it’s not for general consumption.
This wasn’t about getting a wide release — we’re not inclined to fill our store with one-week apps. It’s about proving the iterative process, and our experience with the technology. On real projects, we iterate more than once!
Despite passing review, it’s actually also probably against Apple’s guidelines. Without this post, or similar background knowledge, it’s not obvious to Apple, but this is clearly not a finished product.
2.2 Beta Testing
Demos, betas, and trial versions of your app don’t belong on the App Store — use TestFlight instead.
It’ll remain on Testflight (but tentatively poised for release, at the press of a button!)
This article was made possible by Dubit.
