Please be patient as we perform some upgrades to enhance your experience here on iosbrain.com. For example, we’re producing more video content on our YouTube channel, better organizing our current content, and adding fresh new content that goes beyond developing apps for iOS and macOS. For example, we’ll be looking at the financial performance of Apple’s stock and the stock of related companies, all while sticking to our original purpose of helping developers improve their skills and learn about cutting-edge technologies. Check back soon!
Author: Andrew Jaffee
DevOps: Installing macOS 13.0 Ventura and downloading/installing older available macOS versions
Apple likes to publish a new Mac operating system every year, including beta versions and incremental builds, and there can sometimes be many of those released throughout the year, like we’ve seen in 2022. On October 24 of this year, Apple graced us with macOS Ventura 13.0. Last year, 2021, the company gave us macOS 12.0 Monterey. Wouldn’t it be nice if you could just get a list of available macOS versions, select the one you want, have that macOS installer app download to your /Applications
folder, and then you can run that installer whenever you’re ready? You can and I’ll show you how. Here’s what you see after you download the installer for macOS 13.0 Ventura (installer highlighted in green):
More specifically, I’ll tell you how to install Apple’s new and first alpha version of its desktop operating system software, macOS Ventura 13.0, from a Mac that is most likely still on macOS Monterey — especially if you keep up with the Apple world. I’ll also tell you how to download installers for approximately every public macOS build number within the last two years.
Terminal
command called softwareupdate
. It’s very reliable. I know everything I show you here today works on Monterey and Ventura and I know the command goes all the way back to macOS El Capitan 10.11. If you’re using softwareupdate
on an older macOS version, just do a man softwareupdate
at the command line and study the help. Here we go…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”
Using SwiftUI and WidgetKit to make your app content indispensable
By using a combination of SwiftUI and WidgetKit, you can increase the visibility of your app’s content and enhance the user experience by placing one or more “widgets” on the user’s iOS Home screen, macOS Notification Center, and/or iOS Today View. Widgets should display your app’s most relevant content, allowing users to get important information with a glance. When a user taps/clicks a widget, they go straight to your app and should land on a page that gives them more details about what they just glanced at. Take a look at your iPhone’s Today View right now. There are widgets for weather, battery power, maps, stock exchanges — with many more available. For example, you can get an almost-instant read on the current atmospheric conditions by glancing at one of several available weather widgets. This time of year, before I leave the house, I glance at the weather widget to determine if I need a coat and hat before going outside. If I want to get the forecast for later in the day, I just tap on that weather widget to open the respective weather app.
Continue reading “Using SwiftUI and WidgetKit to make your app content indispensable”
async/await – A core construct of Swift 5.5’s new concurrency model
I first published this article on appcoda.com
The goal: readable asynchronous/parallel code
In designing the async
/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 async
/await
in detail, but I will limit my discussion to it. You need to understand async
/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”
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).
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?
1 |
: 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”
We’re still here…
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!
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”