I imagine a lot of the information here is going to go out of date fast, but if you are looking at playground books today, here is where to start.
- The WWDC 2016 talk, Introducing Swift Playgrounds, has a lot of technical detail about the .playgroundbook format and how the LiveView proxying works.
- The demo for that talk is available on Apple’s dev site, but it’s out of date. I’ve been updating it for each iOS 10 Beta (to track Swift 3). Go to my GitHub to get the fixed Talking to the Live View sample.
- The documentation for the .playgroundbook format can be found on the Apple Developer site.
- Erica Sadun, who has written the book on Xcode playgrounds did some early investigations of iOS Swift Playgrounds. You might want to read them — here is Part I, Part II, Part III, Part IV, and Part V.
- Ash Furrow made a playground book linter and authoring tool (source). You can use the linter on any .playgroundbook (however you make it), and the authoring tool allows you to specify the parts of the book in a .yaml file, and it puts each piece in the correct file and folder for you in the .playgroundbook package.
I’ve updated the WWDC 2016 Playground Book sample, Talking to the Live View, to iOS 10 Beta 7. The main changes were:
- New Swift 3 API for CGAffineTransform
- Use of Error instead of ErrorProtocol
- The new syntax for guard let (commas instead of where)
- New Swift 3 DispatchQueue API
- .clear is a var, not a method, of UIColor now
At WWDC 2016, there was a code-sample published along with a talk about how to “talk to the LiveView” of a Swift Playground on iOS. As more iOS10 betas were released (and Swift was updated), this code-sample has become out of date. Here is my fix of TalkingToTheLiveView.
Back in 2008, I learned Objective-C to make my first “iPhone OS” app, Habits. When it was released, Habits looked like this:
This weekend I finally finished v3.0 and made it free.
As this is a developer site, the more interesting thing to note is that Habits was originally made in the first iPhone supporting version of Xcode (with external Interface Builder) and I have been migrating the project file from version to version since then (using 7.3.1 to make the current build).
Some things that were introduced into Habits for this version:
- Swift – all new classes were made in Swift and many existing ones were refactored into Swift
- Accessibility – Since NSSpain 2015, I’ve been running my iPhone with triple-Home to get into VoiceOver (suggested by Hermes Pique in this talk). Doing that made me realize (1) what it was like to use Habits without looking at it (2) how easy it was to make it work properly.
- fastlane – specifically “deliver” to manage the iTunes record and “frameit” for fancy screenshots
- Carthage – there had never been 3rd party libraries in Habits, but I decided that one was worth it this time.
- TOCropViewController – A simple framework that does one thing very well – provide a View Controller for cropping images. I use this instead of the built-in iOS one because it supports locked aspect-ratios.
I look at dozens of tech resumes and StackOverflow Careers profiles a day and I’m glad that more of them have GitHub links with some code to look at. In 2011, I wrote that I thought tech applicant assessment should be more portfolio based. I described what I would be looking for as an interviewer — one point was:
I could use an orientation: I need a starting place. The bigger the project, the harder it will be to jump in and take a look around. Give me what you’d give a new contributor.
Now that I’ve been spending time in GitHub with the intent of understanding a developer, I can see that I need an overview of the whole repository. GitHub’s public profile isn’t customizable and doesn’t do a good job of describing a person’s contributions.
- Create a page with a simple URL on your own domain (e.g. example.com/github) and write a narrative that takes me through your repositories.
- Link to that page in your resume and in your GitHub profile.
What exactly you do on this page really depends on your specific contributions and what kinds of jobs you are applying to. I made a GitHub tour page to dogfood my own suggestion, but also because, as a consultant, I imagine that some prospective clients look at my GitHub. I decided that a reasonable organization of my page was (approximate) reverse chronological order, but that might not be right for you. If you have a particularly popular project, you probably want that at the top. If you are looking to get a job in a specific technology, you should highlight contributions using it. Most importantly, edit the list down to what someone should look at.
Another benefit of this page is that I can mix-in the non-open source parts of projects. For example, App-o-Mat is not open source, but the app template is, so I can highlight a project that you can’t even see very well on my personal GitHub page. I can also describe a contribution where the code isn’t very interesting, but context is.
Whatever your contributions, I am sure that your own organization of them will be a lot better than GitHub’s default.
I am not a TDD zealot (or even really a practitioner), but on The App Guy podcast, Paul Kemp asked me if I had any habits to share as an app developer. I said:
My app developing habit … is get a new passing unit test every day. […] that new green dot is my indication that I’ve at least added a little bit to the application.
This is a habit I started in earnest when I took B. J. Fogg’s Tiny Habits course. My tiny habit was to just run the simulator, and the best way I found of doing that was to run the tests through it. Then, writing a new test for whatever functionality I was planning next just seemed to be the perfect way to extend it.
Once I write that first test, I don’t TDD the rest of the way, but I’ve found that first test to be a good way to warm up.
My own thinking on goals has evolved over the years to:
- Prefer forming processes to outcomes.
- Keep it simple (one physical, one mental and one social/spiritual)
- Monthly reassessment
So, given that, here are the two best things I read this New Year’s about resolutions:
Buster Benson’s Make Better Resolutions ends with this wonderful template:
Cultivate new or existing relationships with people who I can share my strongest interests with by doing X
My mental goal this year is to do 20 minutes of Duolingo Spanish practice every day. Per Ramit Sethi, I started 3 weeks ago.
The second “resolutions” piece I recommend is James Clear’s Forget Setting Goals. Focus on this Instead, which is a perfect introduction on why to prefer systems to outcomes.
I usually focus my physical goal around working out, but after 2.5 years of crossfit, working out is such a part of my routine, that I don’t really need to worry about stopping. This year will be about eating better, and for January I joined in our gym’s Whole 30 challenge (this is both social and physical). I will reassess in a month.
I appeared on an episode of The App Guy podcast that aired yesterday (12/27).
You can have both versions of Xcode on a machine simultaneously.
Here’s what I did
- I installed Xcode5 normally
- I downloaded Xcode 4.6.3 from the Apple developer website and copied that into my Applications folder as Xcode_4_6.app
- I downloaded the iPhone/iPad iOS 7.0.2 ipsw’s from the developer website and loaded them into the 4.6.3 Organizer (Devices -> Library -> Software Images).
- In order to get Xcode 4.6.3 to see an iOS 7 device, you need to start Xcode 5, load a project so that it connects to the phone, and then exit Xcode 5 and start Xcode 4.6.3, You periodically need to do this again (probably whenever you restart Xcode, but not every time you plug in the phone)
One annoyance is that both versions share Recent Projects and will automatically open projects that are open in the other one. It’s usually best to only start one if the other is closed or doesn’t have any projects open.
I also read on StackOverflow that you can get Xcode 5 to create iOS6 apps by making a symbolic link from inside the Xcode 4.6.x app bundle to inside the Xcode 5 app bundle.
If you build iOS apps and send the IPA to others to install, there are a few simple checks you can do before you send it that will make sure it will work.
- Go into your Build Settings and set the “Validate Built Product” to Yes — that way you won’t be able to build if your provisions are wrong. This is the default for new projects in recent versions of Xcode, but check it to make sure.
- Open the IPA that was created. It’s a bundle, so copy and rename the extension to .zip. Then look for the mobileprovision XML file. You should see the device UDID that you intend to send it to.
- Always increase the version # of any build that leaves your machine. If you don’t do this, iPhone Utility or anything else can decide to offer a cached version instead. If you have a good place in your app to show the version, do it.
If #1 above causes you not to be able to build, then use Apple’s Provisioning Troubleshooting guide.
If the device isn’t listed in the mobileprovision file, then make sure it’s added to the provision in developer.apple.com’s certificate area. Regenerate it and download it once it’s right.
Even if you are using a system like TestFlight, you should follow these tips. TestFlight can’t make an invalid app work, and it can’t fix an IPA that doesn’t have all of the device UDIDs in it. All it does is automate over-the-air IPA installs (which is great), but it still operates within the confines of the app distribution system.