I first published this article on appcoda.com
The goal: readable asynchronous/parallel code
In designing the
await construct, Apple is hoping to increase the readability, and thus maintainability, of implementing concurrency/parallelism in Swift. What I see in it are attempts:
- to make asynchronous/parallel code almost look like synchronous/sequential code; and,
- to make asynchronous/parallel code much more semantically clear (more readable, less verbose, compact, doing what it says).
These are laudable and ambitious goals, but I’d say Apple’s heading in the right direction. I’m glad because I write a lot of asynchronous code to keep my apps responsive — to create the best possible user experience for my customers. I have a feeling that most of you write a lot of concurrent code, too.
We’ll walk through how to use
await in detail, but I will limit my discussion to it. You need to understand
await before trying to use Swift’s other new concurrency features, like actors, continuations, the
AsyncSequence protocol, the
TaskGroup generic structure, task cancellation, and a few other concepts.
Continue reading “async/await – A core construct of Swift 5.5’s new concurrency model”
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”
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?
: couldn't parse contents of '/path/to/project/projectName/projectName/Info.plist': The data couldn't be read because it isn't in the correct format.
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”
Some of you have been kind enough to ask why we haven’t been publishing for a few months. Thank you for your concern.
We’ve been busy, but be patient as you’ll soon be seeing us post articles again…
And we’ve got some big plans for the future, including books, online courses, and video tutorials, just to name a few.
Stay tuned. Thanks!
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”
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”
Developers often need to do something many times and at regular intervals. One common application of such a use case is checking some process’s or device’s status, a technique called “polling.” In this tutorial, I’ll show you how to use the Swift 4.2
Timer class in Xcode 10 to repeatedly perform a simple task, every second, for 1 minute (60 seconds) — and update the user interface (UI) on each “tick.” You’ll learn how to start a timer ticking, pause it, resume it, stop it, and do something on each tick. Here’s what we’ll create during this tutorial — and the source code is available for download from GitHub:
To emphasize that the UI remains responsive when a timer is used judiciously, I added a
UISlider to my storyboard and tested my code. Here’s the result:
Continue reading “Using the Swift 4.2 Timer class in Xcode 10”
If you’re one of the brave people who’ve installed Apple’s new Mojave (macOS 10.14) operating system, you may be experiencing extreme sluggishness and steady slowdowns after boot until everything just freezes up and you can’t do anything. It’s really exasperating, but there’s a cure for the freeze-ups… If your Mac’s primary drive has multiple partitions, and/or you have an external drive attached, and/or your external drive has multiple partitions.
Continue reading “The fix to Mojave slowing down to a crawl and freezing”
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”
My original article — “Best Practices for Building Swift Classes” — was published on appcoda.com.
In this tutorial, I’m going to show you some best practices that will help you design and implement classes (reference types) and then safely leverage reference semantics in Swift. Protocol-oriented programming (POP) and value semantics are all the rage now, but a promising new technology doesn’t mean you should throw all your classes away. Why not add some simple constructs to your classes like copy initializers, default initializers, designated initializers, failable initializers, deinitializers, and conformance to the
Equatable protocol? To get real about my sample code, I’ll adopt these constructs in some classes and show you my best practices working in real life for drawing in your iOS app interfaces.
I’ll walk through the process of creating several protocols, creating classes that adopt those protocols, implement inheritance in these classes, and use instances of the classes (objects), all to illustrate my best practices — and to show some of the extra steps you may have to go through when working with classes.
Continue reading “Some best practices for designing and coding Swift classes”