Disclaimer: I am not a lawyer. This is not legal advice. I am not a encryption expert. If you are in doubt, do your own due diligence. I’m confident that “I read it on the internet and they said it was OK” will not be a good defence if the NSA kicks down your door and hauls you away for cyber crimes.
Yesterday, after uploading an app for beta testing, I received this message in iTunesConnect for the first time:
If you are making use of ATS or making a call to HTTPS please note that you are required to submit a year-end self classification report to the US government.
I was a Lucasarts child. As an education on what a good graphic adventure looks like, this was not really much of a disadvantage, but in order to be a more rounded student of the form I want to get a broader history.
Having just developed a plist-based design framework that works in Interface Builder, I’m more interested than ever in using xibs and storyboards to design my views.
I also like using AutoLayout. There are significant advantages when it comes to things like labels that make it so much easier to deal with than manually setting frames everywhere in code. Things like Dynamic Type, accessibility, and localisation all become easier and there’s less room for error.
There are some things that do become more complicated with AutoLayout (mostly transforms) but there are well established workarounds for most of these.
I was recently designing a new app that involved using MapKit and I wanted to use AutoLayout to design a subclsss of MKAnnotationView but this isn’t entirely straightforward.
I have an appearance manager that reads styles from a plist file and applies then throughout the app through the use of the appearance proxy and through notifications to various custom subclasses of the standard UIKit views and controls.
This works great and allows for of a lot of easy features like different coloured themes or dark modes. The major downside right now is that none of the changes to the plist are reflected in Storyboards or Xib files.
In part 1 I took a high level overview of the game. In this part, I’ll get to why I shipped the game if I recognised that it wasn’t that great. Why not try to make it better first?
It is impossible to over-emphasise how important finishing something is for two important reasons. One, the purely practical one of learning what’s involved. Icons, screenshots, videos, descriptions, metadata, marketing—there’s a lot of work and knowing what’s involved lets me plan better for it in future.
Last week I released my new game, Barista! It’s free and available now on the App Store. Today I take a detailed and critical look at what I made and attempt to extract some actionable lessons from the project.
My new game, Barista!, is now available in the App Store!
Barista! is a fast-paced coffee creation game. Can you fulfil all of the orders and get to the end of the day before your Jim fires you?
Orders appear on the blackboard and you’ve got to get ’em made before the time runs out!
With four different types of drinks with various combinations of cups, espresso shots, and mixers, can you harness the power of caffeine to keep track of it all and survive the day or will the pressure grind you up like so many medium roasted beans?
* Four different drink combinations with up to 3 shots per drink to keep you on your toes!
* Bonus Busy Days where you can double your earnings—if you can keep on top of things!
* Up to four orders at once to really test your cool under fire!
* Many levels of coffee-making mayhem!
Created as part of my 100 Hour Game challenge, it ended up taking me around 160 hours to get it to finished product.
This is actually pretty good for me. Usually projects take 2–3 times longer. This only took 60% so…win!
I’m excited to finally get this out there. I’ve learned a lot during this process and I’m eager to take what I’ve learned and get going on my next game.