Category: Developer Tools

Beyond the sandbox: using app groups to communicate between iOS or macOS apps

Apple’s “app group” technology allows a collection of sandboxed macOS or iOS apps from the same development team to all communicate with each other, coordinate functionality, share resources, and/or minimize redundancies. Notice that I said that I can get sandboxed apps to communicate with each other. But isn’t sandboxing a security mechanism meant to keep apps isolated from each other? Yes and no. Apple realized at some point that it would allow apps developed by the same team, with the same Team ID — built by the same people and thus hopefully less risky — to intercommunicate. I’m glad they did as the usefulness of app groups outweighs the dangers.

As long as all developers involved in creating apps meant to be part of an app group can securely share a Team ID from an Apple Developer portal account, they can write apps that can transcend sandboxing. A company may carefully decide to share its Team ID with a trusted partner company, not just with different teams within its own organizational structure.

Member apps of an app group share access to a special group container, a shared folder structure, whose root folder has the same name as the app group ID. In the macOS sample app that accompanies this tutorial, several apps share a preference stored in a .plist file that lives in the special group container. The preference is the background color to be used by app group apps’ UIView instances. If one app sets (writes) this shared background color preference to, say, the color green, other app group members read this preference and can change their view layer backgroundColor property to NSColor.green.cgColor. By starting an app group, I’ve created the beginnings of a group of related apps sharing — centralizing — settings like view color scheme, even if all the apps are sandboxed.

Continue reading “Beyond the sandbox: using app groups to communicate between iOS or macOS apps”

The real importance of WWDC 2021: raw computing power (CPU), raw graphics power (GPU), and big high resolution screens

Photographers can’t professionally fine-tune an image of a mountainous landscape’s foreground and background on a tiny little iPhone screen. A data scientist can’t layout graphs, matrices, vectors, and spreadsheets on a tiny little iPhone screen. A customer service representative can’t troubleshoot a technology problem without searching through several device schematics, handle several different calls at once, be on the phone with one customer, be texting with another customer, and looking at a user’s guide that shows which buttons and switches do what things on a tiny little phone screen. Can you imagine trying to design, read, write, and debug code, and layout your UI with Xcode on an iPhone? (I could on a large iPad or MacBook, but not a phone).

Continue reading “The real importance of WWDC 2021: raw computing power (CPU), raw graphics power (GPU), and big high resolution screens”

Using the ‘plutil’ utility to fix improperly-formatted Xcode plist files

How do you find typos (syntax errors) in an improperly formatted plist (property list) file, especially when Xcode provides absolutely no detail about badly formed XML? I often see plist files with a thousand or more lines of text! In this article, I’ll show you how to fix plist bugs — and do a few other things — by using the little-known plutil command line tool.

How many times have you seen the following error message, shown below in textual and graphical format, when doing a build?

Info.plist build error

Jump straight to the fix or take a minute to read a little background.

Continue reading “Using the ‘plutil’ utility to fix improperly-formatted Xcode plist files”

Using Xcode 10 Instrument’s Time Profiler template to optimize Swift 4.2 code

My original article — “How to Use Xcode Instrument to Optimize Your Swift Code” — was published on appcoda.com.

I still run across curmudgeons who flat out reject techniques like object-oriented programming (especially inheritance and polymorphism), protocols and protocol-oriented programming (especially composition), generics, and closures. On a conscious level, the curmudgeons usually reject these technique because of their supposed “massive” performance cost. On a subconscious level, the curmudgeons don’t understand these technologies. So do we give up all hope or do we accept the fact that compiler designers have come up with brilliant optimizations that ameliorate the use of such high-level technologies? We believe in Swift’s compiler designers. Do we realize that there are great tools like Xcode Instruments that help us find awkward implementations of these techniques and give us the opportunity to come up with our own optimizations? Yes.

Continue reading “Using Xcode 10 Instrument’s Time Profiler template to optimize Swift 4.2 code”

Dividing and conquering your Xcode projects with targets

My original article — “Dividing and Conquering Your Xcode Projects with Targets” — was published on appcoda.com.

In this tutorial, I’ll show you how to leverage Xcode targets to control the massive complexity involved in building iOS (and macOS, watchOS, and tvOS) apps. A lot of time can be saved when developers realize that not everything they’re required to do has to be done by writing software language code, like Swift. Integrated development environments (IDEs) like Xcode offer very powerful tools, like targets, that allow developers to decouple nitty-gritty tasks that used to be done in code (or manually) out into project configuration settings. I’ve found that, because of the sheer number of project settings, developers often take one look at say, Xcode’s long, long list of Build Settings, and want to curl up and pass out. When finished reading this tutorial, you’ll see that you can neatly organize code into one project that’s capable of producing binaries for iOS, macOS, watchOS, and tvOS.

Continue reading “Dividing and conquering your Xcode projects with targets”

Swift 4.2: How the weirdest error message led to reimagining implicitly unwrapped optionals

In this tutorial, I’ll show you how researching and learning about the current programming language you’re using (i.e., Swift) can lead you to new discoveries, a better understanding of the language, and becoming a better problem solver. Recently, I ran into a Swift error that at first had me scratching my head. The error had to do with implicitly unwrapped optionals. My debugging and contemporaneous research led me to the little-known fact that, in Swift 4.2, a proposal “to remove the ImplicitlyUnwrappedOptional type from the Swift type system and replace it with an IUO attribute on declarations” was accepted and implemented. Despite the fact that I followed and covered language changes leading to Swift 4.2, I missed this seemingly innocuous but nonetheless prescient modification.

Continue reading “Swift 4.2: How the weirdest error message led to reimagining implicitly unwrapped optionals”

How drawing works in an Xcode playground

How many of you use freeform drawing in Xcode playgrounds? How many of you understand how drawing in playgrounds work? Xcode playgrounds can serve as great tools for prototyping your in-development apps, whether it be experimenting with algorithms or toying with ideas for app user interfaces. Granted that drawing in playgrounds is not that well documented. So the subject of this tutorial is how drawing in Xcode playgrounds works and a good number of pointers to help you start drawing in playgrounds. Here’s an example of what I’m talking about:

Continue reading “How drawing works in an Xcode playground”

Xcode 9 playground error: No such module ‘UIKit’ (or ‘AppKit’)

While creating a new Xcode playground on my MacBook Pro today, I got the most bizarre error message: “No such module ‘UIKit'”. I was using Xcode Version 9.2 (9C40b). Yes, I know there are more recent versions, but I haven’t had the need to upgrade my MacBook Pro. Parenthetically, I do have Xcode 9.4.1 (9F2000) and Xcode 10 beta 6 (10L232m) loaded on my main development machine. I’ll share the solution to this problem with you in the hopes that you, like me, will learn something new about Xcode today.

Continue reading “Xcode 9 playground error: No such module ‘UIKit’ (or ‘AppKit’)”

Swift 4.2 improvements: #warning and #error compiler directives

The code shown herein will only compile and link in Xcode 10 beta and run on iOS 12 beta and/or OS X 10.14 beta.

We’re in the middle of Apple’s annual product upgrade cycle and this article is the second in a series of tutorials, started last week, meant to highlight the most important new features of Swift 4.2. Today, we’ll look at two two new Swift 4.2 features, the #warning and #error compiler directives.

Continue reading “Swift 4.2 improvements: #warning and #error compiler directives”

Finding memory leaks with the Xcode Memory Graph Debugger and fixing leaks with unowned and weak

In this tutorial, I’ll show you how to track down memory leaks within Xcode via the Memory Graph Debugger, new since Xcode 8. This is a powerful visual tool and doesn’t require you to step out of Xcode and start the Leaks Instrument. Once we identify some memory leaks, I’ll show you how to plug those leaks by using the Swift language’s weak and unowned qualifiers, and talk about the differences between the two qualifiers.

I recently discussed iOS memory management and memory leaks that occur when using reference semantics and reference types (classes) in my tutorials on “Swift 4 memory management via ARC for reference types (classes)” and “Fixing memory leaks — strong reference cycles — in Swift 4.” After reading these articles, you should understand how easy it is to inadvertently encode and introduce a strong reference cycle into your Swift 4 code and thus end up with a memory leak. You should also understand how generally straightforward it is to fix such a memory leak. My sample code in both tutorials was didactic. What about real-world projects with hundreds of thousands or millions of lines of code? Suppose that you’ve heard reports of diminished app performance, low memory warnings, or just plain app crashes. Finding memory leaks in your code is quite cumbersome when trying to debug via rote inspection, setting breakpoints, adding logging statements, etc.

Continue reading “Finding memory leaks with the Xcode Memory Graph Debugger and fixing leaks with unowned and weak”