One of the cool things UIStackView can do for you is make it easy to dynamically update your app's user interface while it's running, with smooth animations and not a lot of code. My recent talk at iOSDevCamp DC covered some techniques. Natasha the Robot wrote a couple of great posts based on my talk, and today I'm going to talk about another unexpected (to me?) use of stack views. Animated Updates with Stack Views Stack views exist to figure out the layout constraints for their arranged subviews. But only for the stack views that are visible. It might seem obvious but stack view layouts don't consider subviews that don't appear on the screen. The great thing about this is that you can dynamically update your UI just by changing the value…read more →
Category Archives: iOS
As I mentioned in my last post, last week I did a talk at iOSDevCamp DC where I talked about UIStackView, a relatively new UIKit class that's my new favorite thing in iOS development. I'm going to cover some of the more useful things UIStackView can do in posts here, which will fall more or less into two categories: Simplified and flexible UI design, making common UI patterns easier to implement and modify. Dynamic UI updates when apps are running, including UI animations and updates triggered by size class changes. Today I'll hit point #1 above. The cool, useful thing is this: Stack views make (most of) your autolayout constraints unnecessary, for common linear UI layouts. Side by Side Comparison So let's take a look at what UIStackView…read more →
Last week I did a talk at iOSDevCamp DC, an annual event hosted by Luis de la Rosa. I talked about UIStackView, under the admittedly grandiose title of "Mastering UIStackView". I've used stack views for a number of things recently, as I've come to realize they're a lot more useful than a lot of introductory material might suggest. I'll be writing about some of this in the very near future, but in the meantime the excellent Natasha the Robot has already done two blog posts based on stuff that I covered: The Easy Button: A Fancy Animation with StackView Magical View Rotation with StackView Sometimes when I do a technical talk I wonder if people really took anything away from it. Other times, someone does two great blog posts based on the…read more →
I wrote a post a few months ago about sharing data between iOS apps and app extensions in which I recommended using
NSFilePresenter. But I had to update the post to remove that portion when some helpful people pointed me to Apple Tech Note 2408, which read in part:
When you create a shared container for use by an app extension and its containing app in iOS 8, you are obliged to write to that container in a coordinated manner to avoid data corruption. However, you must not use file coordination APIs directly for this.
That basically meant that it was specifically unsafe to use these classes for what would seem to be one of their primary use cases. That sucked.
However last week the tech note was updated, and the above section now reads:
When you create a shared container for use by an app extension and its containing app in iOS 8.0 or later, you are obliged to write to that container in a coordinated manner to avoid data corruption. However, you must not use file coordination APIs directly for this in iOS 8.1.x and earlier. [emphasis mine]
That's great! In iOS 8.2 or higher, the obvious approach should now be safe. I've updated the original post to restore (and somewhat expand) the original discussion of file coordination.permalink
Over the past month or so I've been diving into Swift, after many years of working with Objective-C on Macs and iOS. It's been a change but, gradually, I'm learning the Swift way of doing things. On the way I've run into a few bumps in the road when dealing with Core Data, and I thought would be useful to share how I got past them. Xcode Generated Subclasses Considered Harmful This is the main impetus for this post. Most other stuff I would expect people to work around eventually, but this one is kind of big. Xcode's generated NSManagedObject subclasses are limited but useful in their own way. If you don't need much, they'll do. Everyone else would use mogenerator. That's if you're using Objective-C, though. With Swift there's a decent…read more →