Tag: swift

Software Dev

Clarity is (even) more important than brevity

patmcgLeave a comment

I have published a post or two about the powers of brevity. But we programmers sometimes take it too far.

Can someone tell me what these integers represent? 

case upc(Int, Int, Int, Int)

No? Me either.

This is how associated values are pretty much always done in Swift. But thanks to this post by Marco Eidinger via iOS Dev Weekly, I discovered something new and clarifying: it turns out that you can actually label your enum’s associated values too. People just don’t do it for some reason. 🤷🏻‍♂️

Can you tell me what the integers represent now?

case upc(numberSystem: Int, manufacturer: Int, product: Int, check: Int)

Isn’t that a little easier to understand?

I run into the assumption sometimes where people mistake brevity for efficiency. Brevity shouldn’t mean sacrificing valuable context for slightly fewer words. Thanks to the Marco Eidinger post for pointing this out explicitly. 👍

Clarity is more important than brevity.

Marco Eidinger
Software Dev

Everything you need to know about [weak self]

patmcgLeave a comment

This is a post about the idea of “weak self” in the Swift programming language. It is not a post about self-doubt. You are strong. You are capable. You matter. 😉

But your Swift object might be weak, or at least @escaping and weakly held. 🤷🏻‍♂️ If this makes no sense, maybe it’s time to check out some pictures or quotes.

If you’re a Swift programmer, you probably know that if you need a reference to back to the calling self in a closure, and that closure might last longer than self, then you should send that closure yourself as [weak self] so you don’t end up with a retain cycle and a memory leak.

Via Chris Downie

Still, it can get a bit confusing. What do you do if the weak self is actually gone when you execute the closure? Can the weak self disappear in the middle of the closure?

Fortunately, the Swift blogger Christian Tietze has all the answers. Or at least he has found some answers and summarized them nicely.

In the end, it all points to Chris Downie’s rules of thumb.

Only use a strong self for non-@escaping closures (ideally, omit it & trust the compiler)

Use weak self if you’re not sure

Upgrade self to a strongly-retained self at the top of your closure.

Via iOS Dev Weekly.

Software Dev

“What you can see here is that I was learning…”

patmcg1 Comment

I love this post from swiftjectivec.com.

👉 Things I Made That Sucked

Not only does he detail the interesting stories of some old apps he made, but also the valuable lessons learned from each app that he shipped.

Highlights

Aim first, then shoot. “Ask yourself why you’re doing what you’re doing and channel your excitement into less action and more thinking before you fire away.”

Pace yourself and don’t complicate. “Take time to learn about design and holy moses don’t toss in an open source project just because it’s shiny.”

There is no overnight success. “Always remember that character is carved out rather than instantly created. Each of these misses can eventually add up to a win.”

My own lessons

Applying the same thought process to my own old sucky apps, here is what I come up with…

Where in the World is Santa Claus?

Ignorance is bliss. I genuinely thought it would be easy to make an augmented reality Santa tracker as my very first iPhone app. Who cared that built-in AR support on the iPhone was years in the future?

I understood that I’d have to learn Objective-C and Xcode as I went. However, I did not appreciate how much there was to learn about location APIs, motion APIs, audio APIs, audio editing, 2D animations, CoreData, the State Pattern, linear algebra 🤯, the terrors (at the time) of shipping in the App Store, plus legal/privacy matters. Also why not translate the app into six languages, starting with Spanish?

And all just to see Santa blink on your screen when you pointed your iPhone north. 😆

My blissful ignorance allowed me to jump in fearlessly and forced me to conquer a mountain of challenges as I went (or quit).

This app only ever sold a few hundred copies but was a goldmine of experience and made me a mobile developer.

Bedtime Balloons

Simpler is better. App #2 was more useful and less technically challenging than the AR Santa app. Bedtime Balloons let me get into some fun art and more interesting animations. Plus this app actually made a difference in at least a few people’s lives.

Third-party frameworks can kill your app. At the time, there was no standard 2D animation engine for iOS. SpriteKit was not a thing yet. 🤷🏻‍♂️ So just like the Santa app, I built the animations around the very nice Cocos2d engine, which would eventually morph and evolve and… break my app. 🤦🏻‍♂️ Yeah, I could have rewritten my app, but again only selling a few hundred copies, I chose to avoid all the sweat and tears and just move on.

Continuous Math Cards

Be practical. I never expected to sell many copies of my barebones but highly configurable math flashcards app for kids.

Written quickly in the new (at the time) Swift language, the app was alright. 🤷🏻‍♂️ But it worked for me professionally. My next step would be a full-time day job as an app developer, which had long been my dream.

Software Dev

Why asynchronous programming is (was) hard

patmcg1 Comment

One of the most difficult things about mobile development is asynchronous programming, which means doing different things at the same time. This is not the normal flowchart-style sequence of traditional programming.

Weirdly enough, with Swift completion handlers, an asynchronous function exits before it finishes. Or if you’r not careful, it might never finish at all. 🤯

Oh no! This is entering annoying quantum mechanics territory. 😭

If none of this makes any sense to you, then you’re not alone.

All of this is why I love the following video from WWDC 2021. Nate spends the first eight minutes showing how downloading an image and generating a thumbnail quickly becomes “verbose, complex, and even incorrect” in traditional Swift programming. (Side note: I like how Nate apparently worked hard on his hand gestures as well.)

The payoff: Nate then explains how async/await will let you write asynchronous code basically like “regular code.” 🤩