Under The Bridge Under The Bridge

Category: Miscellanea
The Nib-lunged Saga

We’ve historically been big fans of Interface Builder for slapping stuff out there in a hurry mostly by ourselves, but these days working on a pretty big app (200+ nib files) that’s expeditiously transitioning to modernity under the tender care of a rapidly expanding team (join now!) the downsides of visual tools for maintainability, code review, and merge conflicts become … substantial. Soooo, we’re considering that as it comes up to refactor in The Great Swiftening, we drop the whole nib/storyboard concept and go code only. If that situation is on your radar as well, take a look at the roundup here from last fall:

Working Without a Nib

My goal is to make all my projects nibless. Nib and xib files have caused me no end of problems. Even files that haven’t been edited in years spontaneously stop working when Xcode is updated and its xib compiler changes. (Most of the problems manifested on previous OS versions, where it was harder to detect them and to test fixes.) And that’s to say nothing of the advantages that doing interfaces with code offers. I’m convinced that with current technology (e.g. Auto Layout, Swift), using Interface Builder is a poor time investment for non-temporary projects…

Particularly like this addenda:

I use xib’s for everything in Keyboard Maestro. And have special Lint code to detect inconsistencies. Coming to the conclusion I’m an idiot.

Heh. For a deep dive into the code only alternative, check out

IB Free: Living Without Interface Builder and Loving It

However, once my projects increased in complexity, I found myself becoming more and more frustrated: when designs evolved, I would often just have to start the layout over by clearing all constraints. I often couldn’t get complex layouts to work in IB and I did not understand UIKit well enough to implement anything that IB didn’t allow out of the box. This frustration was compounded immensely when I began to work on projects with multiple team members and source control: I couldn’t understand what other team members had done by looking at a diff of xibs or Storyboards, let alone untangle a merge conflict…

Nodding along there, are you? Yeah, us too.

In this blog post, I’m going to describe the benefits of being IB-free, and will show you how to build a project and control a view’s layout using Anchorage.

That last library, that’s what tipped us all the way. Check it out:

Anchorage: “A collection of operators and utilities that simplify iOS layout code.”

A lightweight collection of intuitive operators and utilities that simplify iOS layout code. Anchorage is built directly on top of the NSLayoutAnchor API, so fully supports UILayoutGuide. Each expression acts on one or more NSLayoutAnchors, and returns active NSLayoutConstraints.

Seriously, they’re not kidding about the “lightweight”. iOS 9 layout API is already pretty darn good, and Anchorage makes it look downright fluent. Definitely going to give that a shot at our current Swiftification and see how it works out!

UPDATES:

A Case For Using Storyboards on iOS

Eject from Interface Builder

Easier Swift Layout Priorities

Hailing Frequencies Open

OK, now that was unexpected in a point release:

Managing App Store Ratings and Reviews

iOS 10.3 introduces a new way to ask customers to provide App Store ratings and reviews for your app. Using the SKStoreReviewController API, you can ask users to rate or review your app while they’re using it, without sending them to the App Store. You determine the points in the user experience at which it makes sense to call the API and the system takes care of the rest.

When iOS 10.3 ships to customers, you will be able to respond to customer reviews on the App Store in a way that is available for all customers to see. (This feature will also be available on the Mac App Store.)

Well, that sounds promising, doesn’t it now? Although when you actually look at the new API, there’s some interesting restrictions:

requestReview(): Tells StoreKit to ask the user to rate or review your app, if appropriate.

Although you should call this method when it makes sense in the user experience flow of your app, the actual display of a rating/review request view is governed by App Store policy. Because this method may or may not present an alert, it’s not appropriate to call it in response to a button tap or other user action…

When you call this method in your shipping app and a rating/review request view is displayed, the system handles the entire process for you. In addition, you can continue to include a persistent link in the settings or configuration screens of your app that deep-links to your App Store product page. To automatically open a page on which users can write a review in the App Store, append the query parameter action=write-review to your product URL.

If your first reaction is that you want to control the presentation, go ahead and dupe this Radar

Allow user-initiated App Store rating/review request alert

although we’re going to go out on a limb here and assume that the lack of that ability is a quite deliberate decision, kinda hard to imagine them just forgetting about doncha think? so it’s not likely to happen. But we shall see.

Some more details have trickled out as well:

Apple explains the new App Reviews API for developers

Apple is also limiting the amount of times developers can ask customers for reviews. Developers will only be able to bring up the review dialog three times a year. If a customer has rated the app, they will not be prompted again. If a customer has dismissed the review prompt three times, they will not be asked to review the app for another year. Customers will also have a master switch that will turn off the notifications for app reviews from all developers, if they wish to do that. On iOS you can now use 3D Touch to label a review as “Helpful”, a feature that wasn’t available before for iOS users…

Additional Details on the New App Store Review Features

The replies that developers will be able to leave on App Store reviews will be attached to the user review to which they’re replying. It’s not a thread, per se, because users can only leave one review, and developers can only leave one response to each review, but they will be connected visually. Users can then edit their review, and developers can then edit their reply…

The new APIs will be eventually be the only sanctioned way for an iOS app to prompt for an App Store review, but Apple has no timeline for when they’ll start enforcing it. Existing apps won’t have to change their behavior or adopt these APIs right from the start…

So there you go, start planning your New Improved Review Begging UX now!

UPDATES:

How & when to ask for app reviews and ratings including iOS 10.3

Notifications Are Better Than Alerts

How to Respond to Apple App Store Reviews and Create Raving Fans

Replying to App Store Reviews

Replying to Reviews

Slopes Diaries #19: App Store Review Replies

Paleo App Dieting

No doubt you’re aware that bigger is not better for downloads on the App Store, especially if you hit the dreaded 100 MB cellular download limit, but were you aware that even if you haven’t there’s a marked disadvantage to download size increasing? Well, here it’s quantified by way of Actual Real Life Experiment:

We bought a successful app, loaded it with extras and watched it fail

… we estimate a linear change in install conversion rate below the 100MB cutoff of -0.45 percent install rate per MB. Above the 100MB cutoff, we estimate a linear change in install rate of -0.32 percent per MB. To our best estimate, the gap between the two lines is covered by a 10 percent instantaneous install rate drop across the cellular download limit.

Although Apple says the cellular download limit is 100MB, we found in practice that a 101MB IPA did not trigger the cellular download block. The actual limit was somewhere between 101MB and 123MB, and it varied depending on the exact build.

Increasing the size of our app from 3MB to 99MB reduced installs by 43 percent, and the increase to 150MB reduced installs by 66 percent in total…

They’ve put together a handy App Readiness Guide with an especially handy App Size Calculator to let you check out your favourite apps.

Sooo, how do we get our size down? If you’re shipping to iOS 9 and later, there’s great options:

App Thinning (iOS, tvOS, watchOS)

  • Slicing is the process of creating and delivering variants of the app bundle for different target devices
  • Bitcode is an intermediate representation of a compiled program. Apps you upload to iTunes Connect that contain bitcode will be compiled and linked on the store…
  • On-demand resources are resources—such as images and sounds—that you can tag with keywords and request in groups, by tag. The store hosts the resources on Apple servers and manages the downloads for you…

Those are generally pretty straightforward to adopt, although you may have occasion to refer to

But if you’re still shipping for iOS 8, none of those help your iOS 8 users at all. Ah well.

First thing is to make sure you’re stripping debugging symbols and dead code with Xcode build settings. Also, make sure that Xcode isn’t bloating your asset catalog behind your back. The setting for that is “Optimization” aka ASSETCATALOG_COMPILER_OPTIMIZATION — and if you haven’t set anything, apparently it defaults to “time” which undoes all your compression and bloats up wildly besides. So set it to “space” instead.

If you need to dig deeper than that, here’s some useful tools for messing with your binary and asset catalog to figure out just what’s going on:

Bloaty McBloatface: a size profiler for binaries

Crunch: “Extract resources from iOS apps. Make iOS icons.”

cartool: “Export images from OS X / iOS .car CoreUI archives.”

AssetCatalogTinkerer: “An app that lets you open .car files and browse/extract their images.”

iOS-Asset-Extractor: “A tool to extract image assets from the iOS SDK.”

And if you need to go still deeper into smallerizing those graphics, well then you’ll have to go to some work. Possibly useful approaches include:

PaintCode is your goto tool for converting vectors into code — and it now supports Swift 3, Android, and JavaScript!

Or you could use SVG files as resourcesMacaw is a new library that looks particularly good for that.

TexturePacker is your goto tool for creating sprite sheets, if that suits your resource usage profile.

ImageAlpha + ImageOptim is an effective strategy for reducing PNG sizes.

JPEGmini is particularly good at making JPEGs smaller.

Or, you could go with the generally well regarded WebP image format, supported by iOS-WebP for instance.

Any more tips? Share and enjoy!

UPDATES:

Well, now that they just introduced HEIF at WWDC ‘17, hopefully all this will be of historical interest only soon, but until you ship iOS 11 only:

Squash — Web Image Compression By Realmac Software is reputed to be worthwhile

So is Guetzli, a New Open Source JPEG Encoder which is in the latest ImageOptim beta

ImageOptim-CLI “Automates batch optimisation of images.”

One Weird Trick to Lose Size

Audit Those Version Checks!

Here’s an extra-special class of problem to watch out for in your iOS 10 testing: Brain-dead version checking. Remember the gales of laughter we all had at those silly, silly Windows programmers when they had to skip Windows 9 because of Windows 95 version checks? Well, this is pretty embarrassing, but apparently there’s a good number of us that aren’t any smarter than Windows programmers:

That’s just painful. But there can’t be that many instances of that out there, right? Right? Let’s check this fine article:

Efficient iOS Version Checking

A GitHub search shows that there are over 8000 results calling substringToIndex:1. All of that code will break with iOS 10. It will instead assume iOS 1, where the only apps that existed were jailbreak apps.

Oh, dear. Well, we know that of course you personally, Dear Reader, would never do anything like that … but we very strongly indeed suggest that you do as full an audit as possible of any codebase you expect to be running on iOS 10 to make sure the Evil Code Elves didn’t sneak anything like that in behind your back.

Read the article for more discussion than you probably need of various ways to address this problem. We say “probably” because you’re all programming in Swift now, aren’t you? so you can just use Swift’s #available operator if you really need to check a specific System version. If you’re not, hey the article dives into its implementation, so copy what you need!

PSA: File Those Radars

Yep, you’ve heard this before if you’ve been around a while, but it can’t be repeated too often:

File radars early and often: The importance of bug reporting

There’s a longstanding debate in the Apple developer community over the value of filing bugs through the Apple Bug Reporter system, commonly known as Radar. Some believe it’s invaluable, the only way to give Apple the feedback they need to ensure bugs get fixed. Others believe it’s valueless, a black hole from which little action or satisfaction ever escapes…

Right now, though, right when the first betas hit, there’s some breathing room. And that’s where radar comes in. If someone at Apple wants to get a bug fixed, they need a radar to point to. If they want to get a bug fixed as a matter of priority, they need a lot of radars to point to. Otherwise they simply won’t be given the time to do it.

That’s also why it’s meaningless whether or not someone else has already found and filed the same bug. First, if everyone assumed that, no bugs would be filed. Second, duplicate filings can be considered like “up votes” that, in volume, shift priority more than they do individually…

So, if you are a developer working on iOS 10, macOS Sierra, watchOS 3, or tvOS 10 apps and you’re encountering bugs, please consider filing radars early and filing often.

Even if you never hear back about them, there are people working on those operating systems right now, people who want to make great software and provide for great experiences — people who will deeply appreciate the radars you file, and your having their backs.

Worth reading it all, but that’s the main points — even though Radar is pretty much useless as a communication tool, it’s the only way to contribute to internal priorities there is. For instance, consider the suggestions in this excellent article on that new Apple File System:

Although APFS does checksum metadata blocks it does not do anything to provide resilience for data blocks. That is a huge omission in a modern filesystem, a point I tried to politely but forcefully make in the File System Lab directly to a responsible engineer. I got the feeling that the APFS team is divided on the necessity of this feature and some people on the team would appreciate some ammo to help win the argument internally. I would encourage anyone who agrees to file radars ASAP requesting this feature…

More importantly filing radars is effectively a vote for a feature and the APFS team is listening. You will never have a greater impact on APFS than going to bugreporter.apple.com and filing radars requesting missing features like parity on data blocks or copying snapshots.

Update: Here is my radar on Data Block Integrity if you want to duplicate it. Even if you copy-paste it your separate report counts as another “vote”.

And if you’re not convinced yet that it’s worthwhile to put in this effort … at least dupe @steipete’s Expose verify state

Steps to Reproduce:

Write a radar

Get it back for review

Observe that it’s simply “Open” no matter the internal state

Expected Results:

An additional exposed field that shows if there have been significant changes.

Actual Results:

We need to rely on guesswork or subtle language changes (which are inconsistent though) to try to guess if there has been progress.

to help out the people who do all the work here!

APPENDUM:

Hmmm — looks like the wide consensus that filing duplicate Radars is a valid way to indicate support may be incorrect:

https://twitter.com/ashtondev/status/750263229926940673

If you happen to have any informed perspective on this issue, please share!

UPDATES:

Writing good bug reports

Have a Simulator problem? File That Radar, then send it to Russ Bishop!

Brisk: “A macOS app for submitting radars”

WWDC16 TL;DR

So that was a bit of a relief of a WWDC this year, eh? Generally in line with the more sober predictions, no massive upheavals anywhere, nice steady evolution and new integration points in all sorts of interesting places! Even keep 32-bit for another year, only the clearly underpowered A5 devices got dropped this time around. Videos are pouring into WWDC.app for your viewing, and while you try to block out the time to watch them all and join the discussions at WWDC16 on Github, which looks like a neat idea:

The purpose of this project is to create a place where the exchange of opinions about WWDC16 sessions can take place. For each video there is a corresponding GitHub issue that serves as a place for a discussion regarding a specific video. Enjoy!

here’s some links to get you up to speed:

Andy Bargh’s newsletter this week, WWDC 2016 Initial Impressions quickly hit the high points for developers.

Op-Ed on WWDC 2016: What We Got, and What We’re Still Missing is a solid evaluation of the tentpole user updates this time around.

iOS 10 Tidbits: Individual Read Receipts, Wake Alarm, Music Storage Optimization, and More is a good hub for discussions of the subtler changes in iOS 10 you might have overlooked so far.

But the immediate concern for most of you — well, after Swift 3.0 Preview 1 Released!, but that we knew about already — is most likely Xcode 8, which you’ll be pleased to hear looks like a pretty sweet upgrade all around:

What’s New in Xcode

Xcode 8.0 beta Release Notes

We particularly like that it’ll support both Swift 2.3 and 3 to ease the transition there.

and get this, Travis-CI already supports the Xcode 8 Beta initial release! Nice job, guys.

And boo! They killed Alcatraz, but yay! for Xcode Extensions — A brave new world

So that’s Xcode. For API changes, start out with

What’s new in iOS 10 for Developers

and move on to the various backgrounders from the mothership:

Foundation Release Notes for OS X v10.12 and iOS 10

What’s New in Core Data in OS X v10.12, iOS 10.0, tvOS 10.0, and watchOS 3.0

If you mobile:

If you desktop:

If you Safari, watch, tv, or whatever, run down the rest of the release notes list:

In other news, the App Store Review Guidelines were completely rewritten; check out App Review Guidelines: The Comic Book. Yes, the comic book. And keep an eye on AppStoreReviewGuidelinesHistory.com for updates as the new format gets digested.

The Human Interface Guidelines are completely rewritten as well — bigger fonts! obvious buttons! cards! — and the API Reference has a sharp new look and organization too. The Apple documentation beavers have certainly been busy!

And if you have a bit more time, go poke around Guides and Sample Code some more and check out all the new code goodies added this week.

What, yet more time? Write an article about some particularly nifty piece of new kit. Here’s some suggestions for starters:

And for anything we missed here, check out Michael Tsai’s WWDC 2016 Links and BNR’s WWDC 2016: Developer Reading List!

UPDATES:

A quick list of overlooked announcements at WWDC’16

Big, bold, and beautiful: Apple’s design language is changing in iOS 10

iOS 10 UI kit from puzzles.design

WWDC 2016 Viewing Guide

wwdc-downloader: “WWDC 2016 video downloader script written in Swift.”

Ole Begemann’s WWDC 2016 Retrospective

Follow The Script

Between writing our client apps in Swift and looking forward to writing our server apps in Swift, we tend to overlook that Swift can be used as a scripting language as well — seriously, is there anything it can’t do? — so here’s how you do that using Xcode:

A Beginner’s Guide to Scripting in Swift

First, you’ll need to start with a new Xcode OS X Command Line Tool Application … The cool part here is that you can even import frameworks like Foundation. Anything you can do with Foundation, you can put into a script — this includes File I/O, string manipulation, and more … Your script can even accept arguments. Just append whatever you want after your execution command to add your arguments like a regular script…

Scripting is a powerful asset and a useful tool in any programmer’s tool belt. For many iOS Devs, Swift or Objective-C are the only languages they know. If they know Swift, then there is no need to learn Python or another scripting language when writing simple scripts for any automation process.

End-to-end development and deployment with nothing but Swift? Shiny!

Another introduction here:

Scripting in Swift

A shell script is perhaps the most popular command-line scripting language, particularly in the mobile development world. To test the viability of scripting in Swift, we’ll write our markdown converter first as a shell script and then compose a Swift version. We’ll then do a quick comparison of the pros and cons of each script…

And one more example from @ayanonagon (and Swift Scripting talk here):

Swift Scripting By Example: Generating Acknowledgements For CocoaPods & Carthage Dependencies

We started using both CocoaPods and Carthage to manage our dependencies, and we wanted to add a nice little view in our app that shows a list of open-source acknowledgements and licenses. We have around 20 dependencies, and the thought of adding the acknowledgements manually sounded tedious…

Indeed it is. Well, that’s definitely our first experiment in integrating Swift scripts into our production process, then!

UPDATES:

Swift Scripting Redux: Localization

Running The Swift 3.0 Migrator On A Standalone Swift File

Command Line Swift

Scriptarian: “allows you to easily automate macOS using the Swift programming language, providing a modern alternative to AppleScript.”

Marathon “makes it easy to write, run and manage your Swift scripts.”

Scripting and Compiling Swift on the Command Line

How to Make a Web Crawler in Swift

Third Time Swifty

So you’ve no doubt heard there’s a new Swift coming, and asked yourself

What’s new in Swift 3.0?

Swift 3.0 is changing pretty much everything, and your code will almost certainly refuse to build until you make the necessary changes. Seriously, if you thought the jump from Swift 1.2 to 2.0 was big, you ain’t seen nothing yet.

Didn’t we go through this already … why yes. Yes, we did.

In this article I’m going to explain some of the most important changes with as many code examples as I can, and hopefully this will give you some chance to be prepared to update your code when Swift 3.0 goes final. There are many more changes than the ones listed below, but the changes below are the ones that are most likely to hit you…

It’s like the Guaranteed Swift Programmer Employment Act! But don’t get too worked up, we completely agree with the conclusion of that article:

It’s easy to read these changes, some of which are tiny but introduce massive breakage, and imagine that Apple’s Swift engineers are just out to make our lives harder. However, the truth is that they are working hard to make sure Swift is as easy to learn, easy to use, and fast as possible, which are three very different priorities.

In particular, I have been struck by how committed the Apple team are to ensuring their changes are discussed and agreed in the open, as part of the Swift Evolution community effort. Every change above went through extensive community discussion before being agreed for Swift 3.0, which is an incredible thing to behold.

You can get involved and help shape these changes going forward: they are keen to hear ideas from a wide range of users, and it means the future of Swift really is in your hands.

So yes. If you’re writing or maintaining Swift code — and who isn’t? — we MOST strongly recommend you read this article thoroughly, and soon. Even better, get an early jump with How to install Swift 3 today and this sample project for instance. Although we’d figure that a Swift 3 running Xcode is pretty likely to show up first day of WWDC 2016, so no need to get too worked up there.

Speaking of the evolution of Swift, there’s also been a great deal of heartfelt concern voiced recently about a) ABI compatibility being missed in 3.0, and b) Swift never getting @objc on its cross-platform incarnations as the current plans lack, and what that lack of runtime dynamism means. (Spoiler: Horrible things.) Around here, we’re just fine with a) taking as long as it takes to get right, and with b) we’re pretty sanguine that something functional (geddit?) which fits the Tao of Swift will show up to address common use cases; but others find it a far more pressing concern. Great round up by Michael Tsai:

Dynamic Swift

Read that if you need to get involved in a good internet fight! Or even if you’re not, there’s still a lot of good conceptual discussion there, if you’ve got some time being familiar with the debate is worthwhile we’d say.

And speaking of being familiar with the debate, prepare yourself for Swift advocacy by checking out

Why big apps aren’t moving to Swift (Yet)

I strongly believe Swift is the future of iOS development. It’s only a matter of when, and the blocker is the breakneck speed it evolves. For smaller apps, Swift is good enough. For big apps, it’s at least a year away…

Let’s all see what we can do to push that forward!

UPDATES:

Wil Shipley smacks down the griefers in Pimp My Code, Book 2: Swift and Dynamism

How To Install New Swift Versions in Xcode

@ayanonagon’s Favorite Swift 3.0 Features

Ole Begemann’s Swift 3

littlebitesofcocoa.com #243: The Great Swift 3 Rename 🐤

What’s new in Swift 3.0

What’s New in Swift 3 – Part 1 and Part 2 and Part 3

Swift 3 and Declarative Programming

Official Swift Blog: Swift 3.0 Released!

Swift 3 Notes

Optional Non-Escaping Closures

Objective-C id as Swift Any

Updating Strings for Swift 3; Mastering Swift: essential details about strings  

Swift 3 Conversion Steps. Or “The 9 steps to Swift bliss”

Swift 3.0 Unsafe World

Writing Libraries for Swift 2.x and 3.0 Compatibility

Grand Central Dispatch (GCD) and Dispatch Queues in Swift 3

Yammer iOS App ported to Swift 3

Swift 3 and Comparing Optionals

A (mostly) comprehensive list of Swift 3.0 and 2.3 changes

Feeling Testy

Here’s an interesting talk on approaches to testing your apps:

An Artsy Testing Tour

Artsy has four iOS applications; all of them are open source, and all of them take different approaches to testing. Why? Because different testing techniques work better or worse in different circumstances…

Like the bit here on Core Data dependency injection,

You might give an object a Core Data managed object context instead of having it access a singleton. We use dependency injection for stubbed managed object context as well as for the network synchronization code. Energy uses in-memory Core Data managed object context that can be quickly and cheaply created, then destroyed for our unit tests. Part of what we can test is how an object modifies the Core Data stores, so we can create a managed object context, inject it into the object that we’re testing, and then the object does something, and then we can inspect the managed object context to see that the changes that had been performed on it are what we expect…

And you can check out all the discussed implementations yourself from this list:

Every element extremely enlightening!

Another one that came out this week is

Running UI Tests on iOS With Ludicrous Speed [EDIT: Translated to ConditionTester.swift]

They’re using a custom KIF fork, mind you, not the Xcode 7 UI Testing hotness. Well, we like it, anyway.

While we’re talking about dependencies and all, there’s been a lot of developments on that front since our last roundup when Swift and XCTest were both brand new. Wow, seems a long time already, doesn’t it? Here’s some articles and code worth checking out:

Swift: The Only Modern Language without Mocking Frameworks

Better Unit Testing with Swift

Four Types of Dependency Injection in Swift

iOS Unit Testing: Dependency Injection with Structs in Swift

Real World Mocking in Swift

Mocks in Swift via Protocols

Cuckoo “was created due to lack of a proper Swift mocking framework. We built the DSL to be very similar to Mockito, so anyone using it in Java/Android can immediately pick it up and use it.”

iOS Functional Testing With User Stories, Ui Test and Local Server

Testing with Swift – Approaches & Useful Libraries

Continuous iOS Code Coverage With Jenkins and Slather

UPDATES:

Mocking Dependencies with Generics “TL;DR: You can inject code dependencies in a transparent way by using generics and typealias.”

Creating a Custom XCTest Assertion

Testing Dictionaries with Swift and XCTest

Depedency Injection in Swift

Cleanse: “Lightweight Swift Dependency Injection Framework.”

Swifjection: “Dependency Injection library for Swift”

Maintainable Swift Mocks

Kakapo: “Dynamically Mock server behaviors and responses in Swift.” + #254: Dynamically Mocking Network Requests with Kakapo

Making burritos with Swift (or How To Mock Classes You Don’t Control)

Mocks in Swift via Protocols

Running tests with Clang Address Sanitizer; Undocumented Xcode Sanitizer Settings

How to Do XCTestCase tearDown Wrong …and Right

Testing the User Interface with FBSnapshotTestCase

How to Make More Useful Swift Mock Objects

Yoshi: Your Loyal Development Companion “easily create menus and access them via a force touch, multi-finger touch, or a shake.”

Bluepill – Open Source Tool For iOS Testing In Multiple Simulators With Added Reliability Features

Testing in Swift: Protocols & View Models

Testing and mocking without OCMock

Let Your Swift XCTest Methods Throw

XCTest and Optional Unwrapping

Xcode 8.3 new APIs: Waiting in XCTest

Controlling Siri and Asynchronous Testing With XCTest

Deep Dive Into iOS Automation At Grab – Integration Testing

Making Mock Objects More Useful

Mimus: “Swift Mocking Library”

Using protocol compositon for dependency injection

Introducing Protocol-Oriented BDD in Swift for iOS Apps: Part 1

Time traveling in Swift unit tests

Resetting iOS Simulator for UI tests

Why you should co-locate your Xcode tests

Keeping XCTest in sync on Linux

How to test a Swift package on Linux using Docker

XCTest closure based expectations

Tests that don’t crash

PaintCode By Numbers

Been waiting patiently for that vector drawing in code PaintCode vs. Android report we promised last year? Well, that kinda wandered off into the weeds. Oops. However, PaintCode continues its relentless march towards ever greater heights of awesomeness in freeing you from PNG tyranny:

PaintCode 2.3 adds 15+ new features, including SVG export

  1. SVG code generation
  2. PDF, AI and EPS import
  3. Completely rebuilt image export
  4. Animated sequence export (“Great for Apple Watch animations!”)
  5. Copy & paste support from Sketch, Illustrator, Pages
  6. Live shape thumbnails in the Shapes & Groups browser
  7. New multithreaded renderer
  8. Support for cut, copy & paste of entire canvases
  9. Support for canvas multi-selection
  10. New way to find out where your library items are used
  11. New, easy way to replace one library item with another
  12. Replace Symbol with its content
  13. Improved PSD and SVG import
  14. Canvas Arrangement
  15. Built-in feedback form

So it’a a better time than ever to check that out. And besides their own excellent tutorials and documentation, there’s an ever growing oeuvre of tips and samples:

A First Project With PaintCode & The Story of Look Up’s Arrow

Create a Resolution Independent iOS8 App and Set Your Images Free

Using PaintCode to Dynamically Create Images in the iOS Football Manager Game Title Challenge

Working With PaintCode And Interface Builder In Xcode

Xcode Live Views: Killing them softly with PaintCode

Responsive iOS Buttons with PaintCode

Increasing The Tap Area Of UIButtons Made With PaintCode

Creating Beautiful iOS Controls with PaintCode

MMScalableVectorView: “Turns static PaintCode or Qwarkee code into a UIView that honors the contentMode property.”

FKRBlockDrawing “is a collection of two classes and one category to make creating artwork in code a lot easier. It’s great in conjunction with PaintCode, where the graphics in the examples project are from.”

Recreating MKUserLocationView is a great walkthrough of how to do a tricky control that highlights the benefits of PaintCode nicely.

And just in case you’re taking this all seriously, here is what we confidently predict is the most chuckle-worthy UISwitch you have ever seen:

A rapid prototype of UISwitch built with Swift and PaintCode

UPDATES:

Recreating Apple Watch Activity Rings in PaintCode

Core Graphics, Part 1: In the Beginning and Part 2: Contextually Speaking and Part 3: Lines

PaintCode Tutorial for Designers: Getting Started and PaintCode Tutorial for Developers: Getting Started and PaintCode Tutorial for Developers: Custom Progress Bar

Preview PaintCode images directly in Interface Builder

PaintCode Review: Dynamic Graphics Made Easy

PaintCode Sketch Plugin Tutorial (and Sketch users, check out Sketch App Sources!)

CoreAnimation is pure love

Bring Your App To Life with CALayers: CALayers, Paintcode, and **Animations**

PaintCode: How to Make iOS-Ready App Graphics with Sketch App

PaintCode Power User: Text Fields

PaintCode Power User: Library Shadows

PixelCut and PaintCode