There are two keys in your project’s .plist file that allow you to identify your application’s build, wether it’s an Apple submission, an ad-hoc, a development or enterprise build. Good management of these keys can simplify your development workflow specially when it comes to submitting builds to iTunesConnect and getting debug information from users and test devices.
Normally, developing a keyboard interface starts with putting a UITextField, a UITextField, or another UIResponder into your application’s view hierarchy…
And then this component becomes a statement: “From here forth, I declare this view to be a keyboard input view”. Except… Well… it isn’t, or at least doesn’t act like it. Unless you manage the layout of your content by implementing your keyboard notifications, the app’s main view will not respond or adapt to the keyboard update, and all sort of messed up situations can arise from this, like the keyboard overlaying your UITextField, UIScrollViews not being able to scroll or UITableViews not being able to display their last rows of content.
On my first blog post, “Ready… Set… Xcode!“, we ended off with a challenge: to build a utility tool that could automate new project deployments.
There’s a couple of solutions you could use to solve this problem. You could write a Unix script, an apple script, or (if you want to be overkill) a whole dedicated Xcode project. I did, though, suggest that you use this little guy →
Because Automator is simple, fast and allows you to provide easy to use UI feedback. As a tool it is also completely undervalued… And the little A.I. bot is adorable… Yes, I just said it.