Where technology meets something or other

Archive for the ‘iOS’ Category

We have a difficult announcement to make. Beginning today we’re winding down the Parse service, and Parse will be fully retired after a year-long period ending on January 28, 2017. We’re proud that we’ve been able to help so many of you build great mobile apps, but we need to focus our resources elsewhere.

We understand that this won’t be an easy transition, and we’re working hard to make this process as easy as possible. We are committed to maintaining the backend service during the sunset period, and are providing several tools to help migrate applications to other services.

Parse will release a database migration tool and will open source ParseServer. Regardless, this is going to come as a blow to a large segment of the iOS developer community.

Can you initialize an attributed string with CSS-populated HTML? This question popped up in #iphonedev. The answer is: kind of. HTML initialization is meant for lightweight use, not for full page layout. But yes, you can.

This question in particular had to do with whether you could customize list bullets:

As far as I know, you cannot use externally sourced images but if you worked hard enough (and I’m not willing to do that), there are always attributed strings image attachments.

The upshot of all this is 1: I touched CSS. 2: I’m busy trying to figure out error naming. and 3: I figured that if it’s really important you’ll either use a web view or work out a post-hoc way to insert attachments that I’m not willing to spend any time on here but someone will point me to them if I throw out a post.

February may seem early to you to be strategizing about Apple WWDC announcements. For tech writers, it’s crunch time. To plan books, posts, and other coverage, you try to anticipate how big a change is coming up and what areas will be affected.

For example, Victor was asking me the other day what I’d like to see in the next installments of iOS and OS X. My answer is the same as it’s been for years: “Bug fixes and security enhancements.” I’m a bit over the yearly update cycle.

Someone popped up today with a classic iPhone 3GS, looking for docs on the VoiceControl system. Sadly, Apple has long since expunged nearly everything VoiceControl related from their main site.

Following some links, I hopped over to the Internet WayBack machine to find that not much has been saved. Although the main voice control page was there, few of the secondary pages, videos, or assets were archived. (You can still link to a couple of audio clips, and the second one on making calls still plays.)

I finally googled up the iPhone iOS 3.1 user guide, which contains about a page and a half of text. This material is still hosted, and I’d imagine this continuing for the foreseeable future.

It was an interesting reminder about the fleeting nature of information.

Make of this what you will. I’ve interspersed updates into everything that follows.

When I ran my older apps, everything ran at 320×568 on the new devices. To get the following numbers, I created entirely new projects. (Saniul Ahmed tweeted me that you need to provide current launch images to get the new dimensions.) Lesson: Update your launch images or create new projects to take full advantage of the new dimensions.

From the docs: “The iPhone 6 Plus uses a new Retina HD display with a screen scale of 3.0. To provide the best possible experience on these devices, include new artwork designed for this screen scale. In Xcode 6, asset catalogs can include images at 1x, 2x, and 3x sizes; simply add the new image assets and iOS will choose the correct assets when running on an iPhone 6 Plus. The image loading behavior in iOS also recognizes an @3x suffix.” So the 6 Plus is 3x. Right. (Even though it’s reporting oddly in the below info dump.)

Compare and contrast with the marketing text: “The size of the new, higher-resolution Retina HD displays on iPhone 6 and iPhone 6 Plus may be the first thing you notice.” (The same HD mention is here as well.) But the 6 non-plus is reporting correctly for @2x ,not @3x, so I suspect the marketing text is wrong. (Thanks akempgen)

It’s been a pretty exciting summer as far as Auto Layout goes. I’m busy going over material so I can get some dates and work estimates to Trina on a possible 3rd edition of Auto Layout. Between Swift, OSX, iOS 8, and whatever is going to be announced in September, it looks like a particularly interesting place to be.

I can’t tell you how thrilled I am about active, the property that self-installs and removes constraints to their natural destination. I submitted my first radar on this back before the first edition was even published. Now with the third edition, I suppose I’ll be all “Yeah, that’s my radar baby!”

The long iOS 8 summer first gave us left and right layout guides, a la the top and bottom guides we first encountered in iOS 7 but they soon disappeared and have since been replaced by a suite of Margin-based layout attributes:

Comments and properties in the UIView header file indicate a layout tree of margins. I think it’s fair to assume this ties into the adaptive application that runs properly both on full-screen as well as side-by-side.

/*
-layoutMargins returns a set of insets from the edge of the view's bounds that denote a default spacing for laying out content.
If preservesSuperviewLayoutMargins is YES, margins cascade down the view tree, adjusting for geometry offsets, so that setting the left value of layoutMargins on a superview will affect the left value of layoutMargins for subviews positioned close to the left edge of their superview's bounds
If your view subclass uses layoutMargins in its layout or drawing, override -layoutMarginsDidChange in order to refresh your view if the margins change.
*/
@property (nonatomic) UIEdgeInsets layoutMargins NS_AVAILABLE_IOS(8_0);
@property (nonatomic) BOOL preservesSuperviewLayoutMargins NS_AVAILABLE_IOS(8_0); // default is NO - set to enable pass-through or cascading behavior of margins from this view’s parent to its children
- (void)layoutMarginsDidChange NS_AVAILABLE_IOS(8_0);

Unfortunately, the material from WWDC is light on details and these updates didn’t take place until fairly recent betas. Got any insights into how this material will play out? I’d love to hear it. (And thanks in advance!)

I’ve posted before about how the new PDF support in asset catalogs doesn’t really do what we expect (offer resizable vector assets). To make up for that, here’s a class that loads images from PDF files directly, building them to whatever UIImage size you need. Supply a path to the image and a target size, height, or width. If using a size, the functions will scale-aspect-fit to that target. With width or height, they’ll use the built-in aspect and build an appropriately sized partner dimension.

This class is part of my useful things repo, which is where I stash stuff that people may generally find useful. A bunch of classes and utilities are tied to my InformIT write-ups, but others meander there over time because I was inspired for whatever reason.

Are you surprised at how many devs are focused on developing new iOS 7-specific applications this late into the game? iOS 7 has a 2 – 3 month ticking time bomb on it and yet every day, I encounter developers whose primary focus is getting their iOS 7 apps into shape for this autumn rather than building iOS 8 for launch this fall.

Sure iOS 7 and iOS 7 compatibility aren’t going away for a while. Even those devs aware of UIAlertView deprecation are focused on bigger deployment issues. Nearly all of them have irrational partners and bosses who insist on backwards compatibility to roughly the jurassic period. If a new iOS 7 app will work on iOS 8 that’s all they want or need. Taking advantage of iOS 8 features, well that’s for other people.

When you work on books, it’s awfully easy to get stuck in Apple headspace. Take UIAlertView. It’s been deprecated and I keep coming back to that, mostly because deprecated classes aren’t even available in Swift these days. Somehow this keeps resonating to my “It’s dead, Jim! I’m a doctor not a miracle worker” senses. I have to keep reminding myself of the day-to-day realities of the app store as it exists, not as Apple would have it. And yet when developers come to me asking how to build HUDs based on UIAlertView this late in the game, I start going UIAlertController ballistic.

The way I see it, ever since App Store started offering platform-specific upgrades, the pressure to back-support all devices all the time was gone. Unless you’re developing something new but specific to older devices (there’s a big market out there if you’re prepared to fight the tool suite, hi Chris S!), why not keep pushing forward with new releases? It’s not as if older systems can’t still do business with you. And when they upgrade, your newer versions are ready for them to download.

How much back compatibility do you think is necessary, especially if you put out regular updates? If the world is upgrading with you, what are you gaining from supporting those 10% of users who have access to your product but may not be running the latest version of your software? What am I missing here?