Without ChatGPT, it would’ve easily taken me 2–3x longer and a LOT of extra, tedious work. Here are 8 ways I prompted ChatGPT to level up my coding process…

1. Use equivalence

I asked ChatGPT how to do things in SwiftUI using context I understood well — in this case, Swift. Prompting with “what’s the equivalent of XYZ in <language>” was a quick way to help me understand concepts through a familiar language, alongside copy-paste-ready starter code.

2. Write code for me

ChatGPT acted as my ghostwriter for a ton of tasks. There was no need to search for example blog posts anymore. I just told ChatGPT what I wanted, and occasionally even pasted in my existing code for it to update — and voila, the code was written for me!

3. Error detection

When I couldn’t find a bug or was hitting a pesky error, I just pasted in my code to have ChatGPT explain what was wrong! It was remarkable at spotting issues and giving clear explainers, letting me avoid having to Google search for generic error messages. Bye bye hundreds of StackOverflow tabs!

4. Deep understanding

I treated ChatGPT like a mentor. Asking high-level questions led to detailed answers with examples to help me better understand concepts. I then asked follow-up questions when I wanted to know more — again, just as I would with a real-life mentor.

5. How-to help

When I needed help with setup or tooling, ChatGPT provided step-by-step instructions on how to do it in Xcode. It completely beat sifting through Apple documentation or looking for tutorials!

6. Hard-to-ask questions

I came across many questions that Google simply didn’t have the answer to. In this case: what was the system name for what many use as the “settings” icon (⚙️)? Somehow, ChatGPT nailed it — and even wrote out the syntax on how to use it in SwiftUI!

7. Gather summarized info

At one point I was designing a part of my UI where screen dimensions across device models were a major factor. So I asked ChatGPT to gather all that information for recent iPhone models and I magically had everything I needed, neatly summarized!

8. Format anything

This one was a trifecta. I needed:

1. a bunch of story prompt ideas
2. variety in their wording, in a specific format
3. the output as an array of strings in Swift

ChatGPT saved me from having to do a ton of manual work or write a custom Python script. I just copy-and-pasted the array of strings straight into Xcode!

Before you go…

ChatGPT has been a huge productivity boost for me, both as an experienced developer but also as a developer always learning new languages and concepts. I hope this post helps with using ChatGPT to level up your coding process!

And for the parents out there, check out my new SwiftUI app for generating custom AI stories for your kids, powered by ChatGPT (yes, very meta)!

‎Storytime AI

You can reach me on Twitter @nathanwchan, or leave a comment below!

8 ways I used ChatGPT to help me build my first SwiftUI app was originally published in Swift Programming on Medium, where people are continuing the conversation by highlighting and responding to this story.

I recently spent four jam-packed days in Denver at the 360iDev conference, the largest and longest-running independent iOS/Mac conference in the world.

As a newcomer to the iOS development world, and after chatting and getting to know dozens of attendees, it occurred to me that I was very likely one of the least experienced iOS developers at the conference.

I figured writing about my conference experience could bring a fresh perspective to those just starting out in iOS, as well as to those who have been attending 360iDev since the very beginning.

I’ve been a full-stack engineer for the past few years, but recently took the plunge and quit my job to pursue a career in iOS. I’ve now been working in iOS and Swift for about three months, and wrote a bit about my experience ramping-up here. In the past, I’ve attended Python and web conferences, but never one related to iOS.

360iDev was the most impactful conference I’ve ever attended.

Environment

All of the conferences I’ve attended in the past boasted about having thousands of attendees. 360iDev was much smaller — 270 attendees this year. You start bumping into the same people. You start forming connections. You start building friendships.

Due to its smaller size, the conference felt almost casual, which was an entirely good thing. Many events were organized informally and spontaneously via the conference Slack team and the Beacon app (created by keynote speaker @khanlou).

Lunchtime was a free-for-all at nearby food trucks and restaurants. Interest groups started popping up in Slack and Beacon — there were Magic: The Gathering gatherings, doughnut runs, Pokemon Go raids, and shared rides to the airport. I felt like this casualness brought us all closer together.

Due to the size of the conference, the amount of physical space needed was relatively small. This year, 360iDev was hosted in a hotel. There was really only one place to mingle, check out company booths, and most importantly, grab some perpetually available coffee (nice work on that, organizers!).

This ensured that you were constantly running into people and made it easy to coordinate interest group meet-up points. It also left plenty of in-between-session time for connecting with others, as opposed to hustling to the next talk across a convention center.

Speakers and attendees

On my count, nearly a quarter of attendees were speakers. I would be chatting with a random attendee that I bumped into in an elevator, or walked with to a lunch spot, only to find out they were giving a talk that I was planning to attend later in the day. This happened to me several times.

I imagine WWDC would be quite different — a conference where the speakers (Apple employees) don’t stick around much, or at all, to interact with attendees. But at 360iDev, I had many opportunities (via Slack or in-person) to reach out and have conversations with speakers.

Being a popular conference in the iOS community, the conference attracts some of the best and brightest in the industry as both speakers and attendees. I must warn you as a newcomer: it might get surreal. You’ll see folks you’ve been following on Twitter sipping a Coke across the lobby, tying a shoelace in an elevator, or even peeing in the urinal next to you (this happened to me!).

So instead of “putting your heroes on a pedestal,” you’ll see them do normal, human things, and have an opportunity to talk to them.

Talks

The conference had three or four tracks, meaning there were typically three or four talks/sessions happening at the same time. With so many enticing talk descriptions posted, naturally, FOMO enters the mind. Which talks should I attend? What if that one is better than this one?

Luckily, recordings of the sessions are posted online in the coming weeks, and speakers posted slides and other material on the conference Slack channel.

The speakers at 360iDev (at least the ones I went to) typically started with why they were speaking about their topic. They then discussed why it was important to them personally or professionally, rather than jumping straight into what they were talking about.

This format differs from the sessions at WWDC. Those are more focused on the future and what’s new. Watching the speakers at 360iDev talk about what they are working on right now really resonated with me. As a newcomer to the field, it helped me understand their daily struggles and thought processes as iOS developers. And I heard so many tips and strategies to overcome those struggles.

The tracks were also structured so that each session was suitable for developers at all levels of expertise. The talk descriptions were clear when topics were advanced, and I didn’t feel like any of the presentations I attended were too far over my head. None of the speakers assumed extensive prior knowledge on their topics.

For a great overview of talk highlights, see this post from attendee, speaker, and podcaster @timmitra.

(My) Themes and Takeaways

The state of the union keynote had a slide that rang true for me at 360iDev. It simply said: “Help others become who they are.”

Throughout the conference, I would bump into attendees I got to know. They would then introduce me to others they thought I should meet. They pointed me to open-source tools they thought I should check out for my projects. And I even got offers to proof-read this very article you’re reading right now. There was an atmosphere of helpfulness that carried through those four days.

I also felt a sense of enthusiasm that I really hadn’t felt at a conference before. Evening social events were filled with conversations about current projects, ideas for next projects, newly discovered features of the Swift language, and a general excitement for iOS development.

The nature of the fast-paced app industry likely has a lot to do with this. Still, it was hard to come away from 360iDev without feeling inspired and motivated within the firm embrace of the community.

I cannot recommend 360iDev enough to those considering attending an iOS conference in the future. For an introvert like myself, I know full days of conference socializing can be exhausting. But 360iDev broke many of those barriers and created a particularly friendly and inviting environment for its attendees. Denver’s also a pretty cool spot :)

Until next time, @360iDev!

You can reach me on Twitter @nathanwchan, or leave a comment below.

Inside the 360iDev conference through the eyes of a first-timer was originally published in We’ve moved to freeCodeCamp.org/news on Medium, where people are continuing the conversation by highlighting and responding to this story.

Take for example a UITextField ’s text property, which is a String?. We could write the following code to appropriately alert the user when the text field is left empty, while unwrapping the text string for later use:

if let title = textField.text {
    if title.isEmpty {
        // Alert: textField is empty!
    }
    // title String is now unwrapped, non-empty, and ready for use
}

Any combination of guard let or optional chaining, like textField.text?.isEmpty ?? true could’ve been used here as well. Either way, the implementation gets messy, and you’ll be dealing with multiple and/or nested conditionals.

Swift extensions to the rescue!

Extensions allow you to add new functionality to an existing class, structure, enumeration, or protocol type. With a where clause, you can restrict the extension to specific or conforming types.

So how can we apply this to handling the empty string value for a String?? Let’s define a new computed property nilIfEmpty in an extension restricted to optional Strings, which transforms an empty String to nil or returns the original String?.

extension Optional where Wrapped == String {
    var nilIfEmpty: String? {
        guard let strongSelf = self else {
            return nil
        }
        return strongSelf.isEmpty ? nil : strongSelf
    }
}

Now, this allows us to clean up our above code for detecting when a text field is empty to alert the user, while unwrapping the text string:

guard let title = textField.text.nilIfEmpty else {
    // Alert: textField is empty!
    return
}
// title String is now unwrapped, non-empty, and ready for use

Pretty, ain’t it?

This extension could also come in handy when used with higher-order functions like map or flatMap:

let stuff = ["nate", "", nil, "loves", nil, "swift", ""]

let a = stuff.map { $0.nilIfEmpty }
print(a) // [Optional("nate"), nil, nil, Optional("loves"), nil, Optional("swift"), nil]

let b = stuff.flatMap { $0.nilIfEmpty }
print(b) // ["nate", "loves", "swift"]

Before you go…

Have you found any other approaches for dealing with empty optional strings? I’d love to hear them. Leave a comment below, or you can reach me on Twitter @nathanwchan.

Handling empty optional strings in Swift was originally published in iOS App Development on Medium, where people are continuing the conversation by highlighting and responding to this story.

After just over 2 months of immersing myself in the Swift language and tinkering with iOS development, I thought I’d put together my thoughts on why I’ve begun to fully enjoy working in Swift and provide some resources on how I ramped-up from complete beginner to feeling confident in building iOS apps in Swift.

I come from a full-stack development background, which really means I can’t call myself an expert in any particular field of computer science :). But I’ve worked professionally in Python, Scala and JavaScript, among a few others, so my perspective likely bleeds from my past experiences working in those languages.

Note: I have been working in Swift 3, Xcode 8 and iOS 10.

1. Readability

Programs must be written for people to read, and only incidentally for machines to execute. — Harold Abelson

This is a principle I try to live by as a software engineer. So far, Swift has felt expressive and easy to use, while maintaining readability for future-me (or anyone else). It has the feel of what I would think a “modern” language should be, leaning towards simple and as-you-would-expect syntax, doing away with noisy symbols and clunky syntax as a natural evolution from Objective-C.

Here’s an example of how some simple string formatting compares between Objective-C, Swift and Python:

// Objective-C
NSString *name = @"Nate";
NSString *str = [NSString stringWithFormat:@"Hello %@, how are you today?", name];

// Swift
let name = "Nate"
let str = "Hello \(name), how are you today?"

// Python
name = "Nate"
str = "Hello %s, how are you today?" % name

There were several Swift-isms that I had to get used to, and still more I’m learning everyday, but Swift has overall been an approachable language to read and write code in.

For a great article on some intermediate Swift syntax, check this out.

2. Functional programming

Swift isn’t purely a functional programming language, but firmly embraces higher-order functions such as map, filter, reduce and flatMap.

As a brief overview of how functional programming can simplify your code, here’s an example:

// Add 5 to each number in an array, and return the even results
let numbers = [1, 2, 3, 4, 5]

// The traditional, imperative way
var newNumbers: [Int] = []
for number in numbers {
    let newNum = number + 5
    if newNum % 2 == 0 {
        newNumbers.append(newNum)
    }
}

// The functional, declarative way
var newNumbersFP = numbers.map { $0 + 5 }.filter { $0 % 2 == 0 }

You could argue that the imperative way is more readable, particularly when functional chaining and code complexity gets out of hand, but think of these higher-order functions as an additional tool in your tool belt for certain use-cases.

Higher-order functions can be extremely powerful, so for a deeper dive, see this article.

3. Type safety

Swift introduces the Optional type, which safely handles the absence of a value. It forces us to handle the nil case explicitly to ensure we’re not making any bad assumptions about what a variable holds.

For example, when a variable is an optional String, we know that either the variable is a String OR the variable doesn’t have a value. Swift offers a few ways for us to handle this in a safe way (called safe unwrapping):

• guard:

guard let str = strOptional else {
    return
}
// str is now safely unwrapped and is guaranteed to be of
// String type from here on

• if let:

if let str = strOptional {
   print("This is a string: \(str)")
}

• optional chaining:

class Person {
    var pet: Pet?  // the ? means pet is a Pet optional
}

class Pet {
    var numberOfPets: Int = 3
}

let me = Person()
let numberOfPets = me.pet?.numberOfPets
// numberOfPets is an optional Int and will be safely set to nil
// if pet is nil

// Or use "if let" to safely unwrap:
if let petCount = me.pet?.numberOfPets {
    print("Pet count is \(petCount)")
}

• nil and conditional coalescing:

let numberOfPets = me.pet?.numberOfPets ?? 0

let hasPets = numberOfPets > 0 ? true : false
// this can be short-handed to: let hasPets = numberOfPets > 0

There’s a lot to be appreciated with type safety in Swift, and many ways to go about structuring code to be safe and readable using these approaches. It can be frustrating at first because Swift urges for explicit handling of optionals (but doesn’t force safety on you!… see forced unwrapping), making it hard to write hack-y code. But just remember, Xcode is your friend and works with you when using optionals!

At the end of the day, Swift was built with safety in mind, intended to prevent many classes of bugs and runtime errors. It may mean that the language feels more strict, but their hope was that proper and explicit handling of types saves time in the long run.

4. Protocol-oriented programming

I’ll admit, this one took a bit of time to even begin to sink in. There is a lot out there on protocol-oriented programming (POP), structs and value type semantics, don’t repeat yourself (DRY principle) and then there’s the infamous Crusty talk; so this was an overwhelming topic early on for me, and still continues to be.

But things began to click as I dove in and started restructuring my code to use protocols and protocol extensions. By implementing and conforming my classes and structs to protocols (blueprints), and defining protocol extensions (default method implementations), I started seeing patterns of reusability and more modular code, and watched as my Massive View Controllers shrunk in size becoming more manageable. A great side-effect was that I was leaning towards composition as opposed to inheritance, so I wasn’t bloating my objects by super-classing and inheriting properties and methods I didn’t need.

I’m not doing POP justice with this bullet point. There seem to be endless use-cases for taking advantage of all that Swift has to offer with using protocols and value types, and I know I’ve only scratched the surface. Post a comment if you have any POP examples worth sharing!

In addition to the links above, here are a few more resources that I found helpful as I continue to wrap my head around this topic:

• Protocol and Value Oriented Programming in UIKit Apps — WWDC 2016
• Practical Protocol-Oriented-Programming — Natasha The Robot
• Blending Cultures: The Best of Functional, Protocol, & Object-Oriented Programming — Daniel Steinberg

5. Property observers

This is one of my favorite out-of-box features of Swift. Understanding how it works is fairly simple with an example:

var score = 0 {
    willSet {
        print("Score is about to change to \(newValue)")
    }
    didSet {
        print("Score just changed from \(oldValue) to \(score)")
    }
}

score = 50
// Score is about to change to 50
// Score just changed from 0 to 50

One of my favorite ways of using property observers is with updating a table view:

var toDoListTasks: [Task] = [] {
    didSet {
        DispatchQueue.main.async {
            self.tasksTableView.reloadData()
        }
    }
}

toDoListTasks.append(Task("clean kitchen"))
// table view is automatically reloaded!

Note from Apple docs:

The observers [willSet, didSet] are not called when the variable or property is first initialized. Instead, they are called only when the value is set outside of an initialization context.

6. Type inference

The Swift compiler infers type for constants or variables, allowing you to keep your code shorter and cleaner.

var number = 5              // Don't need to use var number: Int = 5
let pi = 3.14159            // pi is inferred to be of type Double
let stillPi = 3 + 0.14159   // Yup, still a Double

view.backgroundColor = .yellow   // Don't need to use UIColor.yellow

7. Custom function argument labels

Another small but nice feature of Swift: custom and omitted argument labels in functions for easier-to-read code.

func moveBox(_ box: Box, from start: Point, to end: Point) {
    // move the box!
}
let aBox = Box()
moveBox(aBox, from: Point(0,0), to: Point(5,5))

Xcode then makes it super easy for you to fill out arguments when calling the method.

8. Swift Playground

Since Swift’s initial release in 2014, playgrounds in Xcode have been around, allowing developers to quickly experiment with live code in an interactive environment, instead of having to continually go through a compile-run-test cycle.

Coming from a Python environment, I would have felt empty inside if this wasn’t possible with Swift, but I think playgrounds are to be appreciated for a compiled language! Swift playgrounds aren’t perfect and can get bogged down and slow to use in Xcode, but it’s still been super helpful as I’ve ramped-up and experimented with Swift code.

I haven’t yet used playgrounds for UI mockups, but I can only imagine how powerful and lightweight it must feel for those used to developing for iOS in Objective-C without the ability to quickly experiment.

9. Open-source

Want to know how Strings or Collections or anything else in the Swift standard library works? Or how about even lower-level implementation details of the Swift language? Well now you can! Swift has been open-sourced since Swift 2.2, and the Swift Evolution project continues to provide transparency with what’s coming in future releases of Swift.

Chris Lattner (founder of Swift) and team knew from day one that Swift would eventually be open-sourced, so kept full commit history all the way back to their very first commit. If you notice in those files, the copyright text says “Copyright © 2014–2015 Apple Inc.”, whereas the checkin was made in 2010! So it could be that 1) the team rewrote git history for some reason, 2) this was intentional to remind them that Apple wanted them to deliver in 2014–2015, or 3) Chris Lattner is a sorcerer.

10. Swift documentation

Apple’s Swift documentation reads like a book. They explain things in simple-to-understand English while laying out great examples, and I oftentimes find answers to my questions directly from their docs (as opposed to Stack Overflow), which I cannot say about other languages I’ve worked in.

I’ve learned about how closures and automatic reference counting work directly from the Swift docs, and even began my Swift journey on their Jump Right In page by building out a simple table view app. They’ve done a really great job with these docs and I’d highly recommend going directly to them before heading to Stack Overflow when working through your next problem.

11. Community

Ok I couldn’t leave this one out, so it’s going to be 11 things I like about Swift.

The Swift community has been more than welcoming as I’ve learned the ins-and-outs of iOS development, working in Xcode and ramped-up on Swift.

First, I love how there have been standards put forth from the wild that seem to have mass adoption, like Ray Wenderlich’s Swift style guide and the super customizable SwiftLint project from Realm for enforcing those standards, driven by the community. It’s given me comfort in knowing that there’s a well established way of doing things that much of the community agrees with, allowing me to focus on the important stuff.

Second, the active, online community of people who have willingly lended a helping hand as I worked through problems and had iOS/Swift related questions. Over my last couple months, I’ve leaned on the iOS developers Slack group, iOS developers on Twitter and countless websites and bloggers dedicated to teaching newbie iOS developers like myself.

Finally, those who built and contributed to the open-source project that is Swift. They’ve clearly built something that people love (4th most loved language!) and we shouldn’t take for granted all the work that has paved the way to what Swift is today.

Before you go…

You might be saying to yourself… this dude can’t possibly have nothing bad to say about Swift?! You’re right, there are certainly things that come to mind that have frustrated me about working in the language. To name just a few: lack of modules/namespacing (although there are tricks), JSON serialization using just Swift Core Libraries was a pain (I’m now using SwiftyJSON) and String manipulation and various String operations were brutal to work with (for good reason; but there seem to be a lot of improvements coming in Swift 4).

I opted to stick with the positives, as my overall experience with Swift has been beyond positive. I have so much more to learn (and be frustrated with), so figured that topic can wait.

Lastly, here’s a list of places I’d recommend for those just starting to learn Swift and iOS development that really helped me:

• START HERE AND BUILD SOMETHING: Jump Right In
• Join this Slack group and say 👋: ios-developers.io
• Ray Wenderlich tutorials
• Sean Allen YouTube videos
• Follow iOS developers on Twitter who tweet/retweet about iOS/Swift (there are so so many, eg. @NatashaTheRobot, @hanning_thomas, @gregheo)
• Listen to iOS related podcasts (if that’s your thing…). I’d recommend starting with the SwiftCoders podcast.
• Subscribe to iOS newsletters for well-curated content and to keep up-to-date with what’s happening in the iOS/Swift community. A few good ones are: iOS Dev Weekly, This Week in Swift (NatashaTheRobot), and raywenderlich.com weekly.
• Browse Github and read about how other projects are structured. Good examples are the Kickstarter, Reddit and Artsy iOS apps (I haven’t gone through all of these myself, but they’ve been commonly recommended to me).
• Try to attend local iOS/CocoaHeads meetups and iOS conferences
• Generally immerse yourself, even if you don’t understand everything you read/listen/watch. It’ll click eventually.

You can reach me on Twitter @nathanwchan, or leave a comment below!

10 things I like about Swift was originally published in iOS App Development on Medium, where people are continuing the conversation by highlighting and responding to this story.