Today I’m sharing a template I use to help gather my thoughts anytime I start on an app:

You can get it here. It’s a Craft Doc template, so you can either duplicate it in Craft or export it to another app of your choosing to use it.

Before I explain the gist of it, I want to be clear on when I use it.

A lot of apps start with pure excitement over an idea. Don’t lose that! Cracking open Xcode right away (especially in the age of lightning fast U.I. development with SwiftUI) is a wonderful way to test a quick idea, or let some creative energy out. Keep doing that.

But, what happens next? For me, that’s when I use this guide to feel out the idea, and sorta validate if I want to actually spend more time on it.

The Flow

The whole point of the template is to carve out the idea, see what else is out there and then finally build it if it seems worthwhile. To do that, I follow these steps (sometimes not in this exact order, but close):

Formation
After I’ve hacked around in Xcode and I’m still excited about the idea, I try to figure out what exactly it is. What’s the idea explained in one sentence? If I had to put it on the App Store, what would the title and subtitle look like?

All are subject to change, but it’s a useful thought exercise for me.

Research
Okay, so I know what it might be - what else is out there? Are there holes in the market I could come in and plug? Of the similar apps, what are they doing well, not well, how are they priced?

This helps me figure out monetization and any other key features I might need to look at.

Mocks
Now, it’s the “messy middle”, where I just sketch out the flow in very low fidelity designs. I want to have an idea of all of the screens I need for a lean MVP to ship. For me, that’s key - I want to think about every screen I’m going to show (which usually correlate to a view controller in code) because it helps me cut scope.

Spec
Here, I write down a focused set of tasks to get version 1 out of the door. I also leave a little room for some “secret sauce”, for example - maybe a custom view controller transition or two.

Design
This step is hit or miss for me, sometimes I skip it altogether. But, I may flirt with making a high fidelity design in Sketch for the app. It helps me really think about those “Well what happens when I press this” kinda situations.

Plus, I know the features I’m aiming for now. I’ve got an MVP spec’d out here, so by virtue of that - I also know what I’m designing.

Build
Not much to say here - time to put code to compiler.

Prepare
The time between starting the project and launching it is a great time to get the word out. This step has some thoughts on how to do that.

Launch
It’s here, launch day. I’ve got reminders covering things to do weeks before, the day before and day of.

Going Forward
Here, you’ve outgrown this document. If all went well, you’ve got a new project to carry forward and improve.

And fin.

I hope this helps! For some folks, a list of stuff like this in a template sounds stressful and rigid. For others, like me, I feel lost and frazzled if I don’t have a somewhat prescriptive set of steps to follow and see where I’m at.

Until next time ✌️

The most impactful change to come out of W.W.D.C. had nothing to do with APIs, a new framework or any hardware announcement. Instead, it was a change I’ve been clamoring for the last several years - and it’s one that’s incredibly indie friendly. As you’ve no doubt heard by now, I’m of course talking about iCloud enabled apps now allowing app transfers:

If you’ve visited my internet home or have been my eFriend for the past few years, you know this is personal for me. I’ve never been one for open letters, but oh how I’ve constructed a pointed missive over and over again in my head about this. I’m glad there’s no reason to anymore.

When my last app, Spend Stack, was acquired - it took nearly four months to get settled. This was an experienced buyer who usually had things done and dusted in one week. Why did it take so long? Because I didn’t just sell Spend Stack, I had to sell my entire LLC, Dreaming In Binary, which I had owned for many years to that point. Instead of transferring the app, I had to manage a slew of logistical hurdles that neither I, or the acquirer, wanted to otherwise.

Now, there is no more creating an LLC per app (what!!!):

CloudKit is wonderful, and it offers so many advantages that most of us went through all of the riff raff you had to go through to form a LLC, open a business account, get your DUNS number and more just to freaking use it for one app! This is a directly pro-developer move from Apple, and one we can all hold hands and agree on. CloudKit gives you so much that Apple should really be pushing it 30 times harder than it has been:

• Hardly any of us want to manage user logins or server data.
• We (developers) all want to support sync, and all customers want sync.
• Of our users, the majority have multiple devices they want to use our apps on.
• No other syncing solution is as smooth as iCloud - we don’t have to tangle with logins or sign ups. People use our apps on their other device, and like magic - their data is there. That’s the most Apple “it just works” experience around. This is a rare user and developer experience win.
• It’s maintained and trusted by one of the largest technology companies on the planet who rely on it. This won’t be another Parse.
• And, not to mention, the best alternative is owned by Apple’s rival - Firebase from Google!

In short, it’s about time. People tend to think that an app getting acquired is only for the bigs, and that’s simply not true. This move allows indies to get a nice chunk of cash and let their project live on from another company taking it over so we can focus on new things…without selling an entire LLC along with it.

The long and short of it is this - many of us would skip iCloud sync altogether because it meant we couldn’t transfer any app using it in the future. In turn, we offered a worse user experience than we otherwise could’ve or we’d use a competitor which wasn’t as good and required user logins (with iCloud, the user is already “logged in” via their Apple ID). It was painful and agonizing every time, because we knew iCloud was the better sync option - but we couldn’t risk having to part with every single of our apps if just a single one using the iCloud entitlement was acquired. No more.

In another reality, if this one image was on a slide during W.W.D.C.’s keynote in 2022 - I venture to say it would’ve received the loudest applause out of anything else they could’ve said:

Until next time ✌️

As we turn the page on yet another W.W.D.C., things are definitely starting to move in that direction. The one we’ve kinda known was coming, namely:

Granted, I’ve seen this quote taken a little out of context. Apple preceded that statement by saying Swift and SwiftUI are the best way to build new apps. So, what about…not new ones?

Hey oh, UIKit! The framework of yore is alive and kickin’, and of course - better than it’s ever been. Let’s see what Cupertino & Friends™️ have added to the framework for iOS 16.

If you want to catch up on this series first, you can view the iOS 11, iOS 12, iOS 13, iOS 14 and iOS 15 versions of this article.

UICalendarView

A brand new component for iOS 16, UICalendarView brings a lot of power to date related operations. Unlike its counterpart, UIDatePicker, it allows for custom decorations for date ranges, multi date selections, font designs and more:

let calendarView = UICalendarView(frame: view.bounds)
calendarView.calendar = Calendar(identifier: .gregorian)
view.addSubview(calendarView)

let multiDateSelection = UICalendarSelectionMultiDate(delegate: self)
calendarView.selectionBehavior = multiDateSelection

And boom:

Using its delegate, you can vend custom views for each date. I could see this being especially useful for situations where you want to highlight a range of dates, perhaps with a “selected” background. Or, you could just make everything a rocket ship because you freakin’ can:

func calendarView(_ calendarView: UICalendarView, decorationFor dateComponents: DateComponents) -> UICalendarView.Decoration? {
	return .customView {
    	let emoji = UILabel()
        emoji.text = "🚀"
        return emoji
    }
}

Resulting in:

I should note, calendar view works in terms of date components, not Date instances themselves. This is different from UIDatePicker, so it’s something to be aware of before you start plugging it in in place of it.

Read more at the docs.

Variable Symbols

SF Symbols is the framework that just seems to go harder in the paint every single year. I would be impressed if Apple simply added to their collection annually (which they do) but they also add new and interesting ways for us to use them. Right on the heels of giving us different rendering styles, now we’ve got the ability to variably fill them:

let glyph = UIImage(systemName: "water.waves", variableValue: 0.2)

In short, we can “fill” the glyph in based off of a percentage value from 0 to 1. This is particularly well suited towards situations where we are trying to convey a sense or progress or status, for example - showing how strong a wifi signal is, or how much battery you have left. Here is a wave glyph using a 0.2, 0.6 and 1.0 variable fill, respectively:

I see a lot of opportunities to get creative with this API. For example, why not wire up Combine (yup, still love Combine) and change the variance of a glyph to show the classic typing indicator:

It can easily be done:

class ViewController: UIViewController {
    private var subs: [AnyCancellable] = []
    let imageView = UIImageView()
    lazy var count: Double = 0.0 {
        didSet {
            let glyph = UIImage(systemName: "ellipsis.message.fill", variableValue: count)
            imageView.image = glyph
        }
    }
    
    override func viewDidLoad() {
        super.viewDidLoad()
        
        Timer.publish(every: 0.35, on: .main, in: .default)
            .autoconnect()
            .sink { [weak self] _ in
            switch self?.count {
            case 0.0:
                self?.count = 0.2
            case 0.2:
                self?.count = 0.6
            case 0.6:
                self?.count = 1.0
            default:
                self?.count = 0.0
            }
        }.store(in: &subs)
        
        imageView.contentMode = .scaleAspectFit
        imageView.frame = CGRect(x: view.bounds.size.width/2 - 50, y: 100, width: 100, height: 100)
        view.addSubview(imageView)
    }
}

Resizing Cells

In a change that is bound to make those of us who’ve longed relied on UICollectionView and UITableView for years cry a mix of joy and relief, cells now automatically resize themselves when their content changes. Note, resize. We’ve had self sizing cells for a bit now. Now though, for example, if you had a label which was hiding and showing, you no longer have to do the magical incantation of invalidating the cell size, calculating its height or really anything else - now, #ItJustWorks. This is on by default:

collectionView.selfSizingInvalidation = .enabled

Worlds Collide - SwiftUI Views in Cells

Speaking of cells - my goodness, this next one slaps. A common thread among many iOS developers is that SwiftUI is amazing for several tasks, but one that maybe requires the fine-tuned touch of imperative programming techniques is when you have lists or queues that require a touch of performance tuning. You can get in the weeds and do what you need to make things fly.

Now, you can combine the ease of use of SwiftUI with your existing table or collections views. Using the recent content configuration APIs, you can vend a SwiftUI view for a cell. Best of both worlds, as it were.

Here’s an existing content configuration from my collection view snip:

let videoGameCellConfig = UICollectionView.CellRegistration<UICollectionViewListCell, VideoGame> { cell, indexPath, model in
	var contentConfiguration = cell.defaultContentConfiguration()
	contentConfiguration.text = model.name
	contentConfiguration.textProperties.font = .preferredFont(forTextStyle: .headline)
	cell.contentConfiguration = contentConfiguration
}

While that works, now you can do stuff like this:

cell.contentConfiguration = UIHostingConfiguration {
    HStack {
        Text(model.name)
            .font(.headline.bold())
        Image(systemName: "star.fill")
    }
}

Tangentially related, this also solves some of the complexity I felt when content configurations were introduced around creating custom ones. Creating custom configurations is absolutely possible, but it takes a bit of leg work. This, well, doesn’t - and that’s awesome.

Little Nuggets

With iOS’ heuristics always improving, you can now detect money or physical values from data detectors:

let textView = UITextView(frame: .init(x: 80, y: 80, width: 200, height: 200))
textView.text = "Let's chat about how much my apps that don't exist make, $0.00 ARR.\n\nSee them here:
https://www.ihavenoappsrightnow.com/becauseImWritingABook"
view.addSubview(textView)

textView.dataDetectorTypes = [.money, .physicalValue]
textView.isEditable = false

As of now, .physicalValue has no overview, so I’m not quite sure what it’ll detect. Money, however, is straightforward.

Oh - you can size sheet presentations now, yes! Personally, the detents that came out of the box last year had limited utility for my own work, but being able to tweak it so they show exactly how I want is perfect. For example, if I needed a super tiny sheet that’s only 100 points tall now, that’s perfectly valid:

let vc = ViewController()
vc.view.backgroundColor = .purple
vc.sheetPresentationController?.detents = [.custom { ctx in
	return 100 
}]

self.present(vc, animated: true)

When you use create a custom detent provider, you can reach into UISheetPresentationControllerDetentResolutionContext to see things like the trait collection or set a maximum value. Neato. Plus, you can set custom detent identifers to use along with all of the properties UISheetPresentationController had before, like setting it for the .largestUndimmedDetentIdentifier property.

More to Discover

There’s a lot that’s changed with context menus, giving them a substantial amount of power and flexibility in terms of sizing and presentation. Plus, a new paste control, page controls that can be used vertically, find and replace options and a lot has been done to the trusty navigation bar. Now it has presets for specific contexts, tailored for things like document based apps or ones that are more creative and free…form 😉:

Final Thoughts

As we see the inevitable rise of SwiftUI, I can’t help but smile as I write another article in this series each year since iOS 13. Right after dub dub, I immediately see the “Here’s what’s new in SwiftUI” articles hit - and why not? SwiftUI is exciting, and I love using it.

But, for now, UIKit is still here and doing its thing. And, wow - it’s added a lot of great stuff this year. And while it keeps doing that, yours truly will keep talking about it.

Until next time ✌️

W.W.D.C. happens Monday, and if it’s your first dub dub - then you likely only feel one thing: massive amounts of excitement. And you should! For me, W.W.D.C. is one of the most exciting times of the year.

However, if you’ve been around the likes of McEnery, braved the halls of Moscone West or (throwback!) traveled through Santa Clara Convention Center then…you know.

Dub dub is amazing, fun and yes - kinda a little stressful. Here’s how I consume W.W.D.C. to come out with a clear mind and a focused direction.

At the risk of sounding like a Buzzfeed article, here are seven tips I live by to handle W.W.D.C..

Realize Everyone is About to be Overwhelmed

Just declare bankruptcy upfront. Not one person will be able to fill their domes with everything that’s about to be announced. The good thing is, you don’t need to know it all.

Just try to be aware of it.

For me, the main thing I want to know about first are the new frameworks added to iOS, so I’ll wait for the diffs here to be uploaded¹. More recently, Apple has taken it upon themselves to show the new frameworks on their technologies page, so let’s hope that work continues.

We’ll know about the big hitters because those will be a part of the marketing, as well they should. But what about the quality of life improvements? For example, the Uniform Type Identifiers framework is killer, yet so many don’t know about it. It can make your code better, but it might be relegated to “word cloud” duty.

Next, Apple’s design pages also have also included a change log of sorts, so that’ll be my next stop. Any design updates will be highlighted, and typically, new technologies (think something like WidgetKit) will have freshly minted design guidelines. Those are key.

My goal here is to have a passing knowledge of what’s new, that way I can make better decisions on figuring out what to dive into later on. What is delayed is not denied, so take a breath and realize you’ll have time to come back to what you want to learn more about.

Take Messy Notes

Next, have a no-nonsense way of taking notes. For me, taking notes at W.W.D.C. is all about being in the frustrating part of forming ideas - the messy middle. I’m going to have a million scattered thoughts, too many ideas to follow up on and several APIs I’ll want to write about.

This is all fine, so long as you’ve come up with a system to take those notes. For me, I use Craft. Here’s what it looked like last year:

I separated everything into one of five buckets (which will look familiar if you follow anything I write), and most of the information I get will fall into one of them. I do this because I know what I’m trying to do at WW.W.D.C.:

• Figure out what to bring to the apps I work on.
• Learn what to write posts about and update my book series with.
• Decide what I want to learn a lot more about.

So ask yourself - what are you trying to get out of W.W.D.C.? That’ll help inform your game plan.

The next three tips are more process orientated, but it helps to know what to do with the first day of W.W.D.C..

Watch the Keynote

This one is obvious, and no doubt - you’ll be doing it. But, I list it here because this is where you likely want to begin with the above tip. Start taking lightweight notes throughout the keynote, because those are things you’re going to want to follow up on throughout the week.

When WidgetKit was announced, I might’ve put something in my notes that simply said “WidgetKit” during the keynote, but then I knew to mark down any sessions in the Developer app released later on to learn more about it.

At this point, my only goals are to become extremely excited about the new stuff and get a 10,000 foot view of what the “big new things” are - because that’s what we will get in the keynote.

Remember, the keynote isn’t entirely for developers - it’s kinda for investors too. Apple’s stock will change after W.W.D.C., it always has. This is not a criticism at all, but it also illustrates that for many, the keynote is about what everyone on the planet should look forward to with the upcoming version of iOS.

Watch the State of the Union

So, if the keynote is for everyone, than the State of the Union is for us.

This is where we get new framework drops, information on the particulars behind some new APIs and generally how the new version of iOS fits into the ecosystem. This is likely the best TL;DR of the week, so you can’t miss it.

After this one is done, your notes should really be starting to swell with a lot of headings and threads to follow up on.

Take Note of Award Winners

Here’s something that some might sleep on, but you totally shouldn’t - watch the Apple Design Awards ceremony. Sure, you can read the recap later - but that’s like being excited about a sporting event and just checking ESPN later for the score.

You want the why behind everything. Try to listen for the Apple evangelist+designer presenter’s reasoning behind why something won what it did. What made it great? Why did it work? They always have gone into detail to try and justify their picks, and I appreciate that.

Winning an A.D.A. is my moonshot goal, it drives me in several ways. Beyond just intrinsically wanting to make neat things that help people, I want to reach the peak - and an A.D.A. is the peak in this business.

So, pay attention here. Even though it’s at the end of a busy day, to me it’s like a nice little reprieve from all of the business that just occurred. It’s usually short too, clocking in at 30-45 minutes if memory serves.

Remember, Apple Developers are Human

Try to have some empathy during the week and consider filing a radar if something doesn’t work as advertised. Here are some tips on how to do that from someone who literally just worked at Apple.

After Monday…

Once the excitement of day one is in the books, I’d encourage you to enjoy the community. Take in all the deluge of Twitter finds promulgated by the community, hang out with other developers and enjoy the moment.

For me, Monday evening is the “smell the roses” moment - I just try to be present and enjoy one of my favorite events of the year. I’ll have all week to learn stuff, but for now I just want swap dev stories with other indies, make new connections and talk shop with Apple engineers.

After Monday, though, I have three goals:

• Schedule Labs: Get information and design tips.
• Bookmark Sessions: Figure out which sessions I can’t afford to miss.
• Community++: Set up some lunches or dinners with other developers - good ol’ fashioned networking.

With that, my week is filled up. I keep taking notes, fleshing them out and then when it’s all over I immediately come up with a game plan.

Final Thoughts

There is nothing quite like W.W.D.C. for me. I so dearly hope it’s restored to its former format of being an in-person event next year, should crazy mutating viruses allow it. My best professional memories are all from W.W.D.C., and being around so many other developers fills me up.

No matter what W.W.D.C. this is for you, don’t stress over it! Realize the information dump you just received is too much to take in at once - you just need to know how to tame it, and then hone in on what’s important to you and your team.

Until next time ✌️

Dub dub beckons, which means that the eighth annual edition of the Swiftjective-C WWDC Pregame Quiz is here! If you want to test your might first with the backlog, here are the previous trivia entries from 2015 ,2016, 2017 ,2018, 2019, 2020 and 2021!

let kickoff = try await trivia(with: .answerKeyAtTheBottom)

Ground Rules

There are three rounds, and the point break down is as follows:

• Round 1 – 1 point each answer
• Round 2 - 2 points each answer
• Round 3 - 3 points each answer

The last question of each round is an optional wildcard question. Get it right, and your team gets 4 points, but miss it and the team will be deducted 2 points.

Round 1 - All About Displays 💻

Question 1:
The first iPhone sported a 3:2 aspect ratio at 163 ppi, but how many pixels was it packing?

A) 480 x 320
B) 320 x 480
C) 280 x 380
D) 380 x 520

Question 2:
Moving on, today we’ve got the Pro Display XDR - a slight improvement over the first iPhone’s display. Sporting a 6k screen and a 6016 × 3384 resolution, how many nits of brightness is the display capable of operating at?

A) 800
B) 1200
C) 1000
D) 1600

Question 3:
Let’s do another throwback - the first iPad, released in 2010. It had a 1024 x 768 pixel display, the largest seen on an “iOS” device at the time. But, do you remember how large its screen size was?

A) 11.2 inches
B) 8.2 inches
C) 9.7 inches
D) 10.0 inches

Question 4:
Sitting below the Pro Display XDR, we’ve got the Apple Studio Display. It comes packed with several features, but which of these is it missing?

A) 600 nits of brightness
B) HDR
C) 5k Display
D) P3 Wide Color Support

Wildcard:
Oh, firmware. The gift that keeps on giving. It’s been stated that iOS 15 drives the Studio Display, and that an update might address its camera woes - but what other Apple product did iOS initially power outside of the iPhone?

A) Apple TV
B) HomePod
C) Apple Watch
D) Pro Display XDR

Round 2 — Watch Me ⌚️

Question 1:
Jony Ive has long said that a watch is a personal device, even a fashion statement. As such, all Apple Watch models have been sold in different casing variants except for which two models?

A) Series 1 and SE
B) SE and Apple Watch Edition
C) Series 2 and 3
D) Series 6 and SE

Question 2:
Each new version of an Apple Watch brings with it a new chip to power it. Of the eight mainline models to ship, all of their chips have been named Apple S[Series Version], so Apple S2 or Apple S4. Which of these names is the only one that has broken that convention?

A) Apple S1P
B) Apple SX
C) Apple SE
D) Apple Sr

Question 3:
As the Apple Watch has matured and found its niche, it’s been branded less as a fashion accessory and instead has leaned into its fitness aspects. Which of these apps launched alongside watchOS 3 to help drive this direction?

A) The Fitness App
B) The Nike Run App
C) The Breathe App
D) The Meditation App

Question 4:
Apple Watch has had many product collaborations over its lifetime, but which one of the following was the very first?

A) Louis Vuitton
B) Nike +
C) Under Armour
D) Hermès

Wildcard:
The first Apple Watch wasn’t marketed as being water proof, and it sported an IPX7 rating. Which Apple Watch was the first that Apple explicitly marketed towards swimmers and surfers?

A) Series 1
B) Series 2
C) Series 4
D) Series 3

Round 3 — Apple History Randomizer 🍎

Question 1:
Apple is known as a technology company today, but in 1986 it introduced “The Apple Collection” - what was the product line for?

A) Notebooks
B) Clothing
C) Furniture
D) Jewelery

Question 2:
Apple is always in the details, as such - each product mock up used in advertisements is always showing the same time. What is it?

A) 9:41
B) 9:45
C) 11:00
D) 1:15

Question 3:
While the Apple I and Apple II were its first products, Apple shifted naming strategies for its next release - instead opting for a regular name instead. What was it?

A) Karen
B) Linda
C) Lisa
D) Janet

Question 4:
Apple is going hard on services right now, branding them under the + moniker. Which of these was the first one to go to market?

A) Apple iCloud+
B) Apple Fitness+
C) Apple TV+
D) Apple News+

Wildcard:
Speaking of “+” releases - these services aren’t the first Apple products to use the word. What was the very first Apple product which had “Plus” in it?

A) Apple Macintosh Plus
B) Apple II Plus
C) Apple LaserWriter Plus
D) Apple III Plus

Answer Key

Round 1:

1. B - 320x480.
2. D - 1600, but only in environments cooler than 25 °C (77 °F).
3. C - 9.7 inches.
4. B - HDR.
5. Wildcard: B - the HomePod, now powered by tvOS.

Round 2:

1. A - The Series 1 and SE.
2. A - Apple S1P, which shipped with the Series 1.
3. C - The Breathe app debuted to facilitate mindfulness.
4. D - Hermès in September, 2015.
5. Wildcard: B - The Apple Watch Series 2.

Round 3:

1. B - it was a clothing line.
2. A - 9:41, since Apple usually introduces a new product dueing keynotes at the 40 minute mark.
3. C - Lisa. Can you imagine the…Apple Janet 😆?
4. D - Apple News+, launching on March 25, 2019.
5. Wildcard: B - the Apple II Plus, shipping in June 1979.