
I was in need of a detour. I've been pretty focused on large projects in the web dev category. So, to scratch the curiosity itch, I hacked away at a very simple iOS app.

I had a few questions I was looking to answer going in. I was largely curious about how big the gulf really was between web development and native.

Additionally, what are the benefits of fully committing to an ecosystem? VS Code is fine-tuned for JavaScript and web development, while Visual Studio is a full IDE for C# and .NET. In that sense, I had some experience, but I was still curious about how this plays out on the Apple side.

Note: I've only given this a couple of weeks of playing around in my off time. Thoughts here are first impressions, not expert opinions from a seasoned iOS dev. Take all of the following with a grain of salt.

## Swift

Apple's programming language for their products is fairly quick to pick up. [The tour of the language](https://docs.swift.org/swift-book/documentation/the-swift-programming-language/guidedtour/) on the swift docs site gets you most of the way there, and most of it is analogous to any other language that supports classes.

### Unwrapping

The one concept that takes getting used to is _unwrapping_. I'll do my best to explain concisely, since I don't want to distract too much from the rest of the post.

Swift has an `Optional` type that you can denote with a question mark. If I were to try to use this value later, I would get a compile time error:

```
let color: String? = nil

print(color) // Warning: Expression implicitly coerced from 'String?' to 'Any'
```

`color` as a variable has reserved space in memory for a value, but it's not guaranteed that the value is there. That is what the `Optional` type is communicating. Hence the warning when `print` receives an optional type.

The swift way of handling this is to _unwrap_ the value.

```swift
if let color = color {
    print(color)
}
```

On the left side of the operator, I'm declaring a new `name` variable for the block scope. On the right, I'm assigning it the value of my original `name` variable. At the start of this line, I'm checking that a value exists with an `if` statement.

By this point, if a value exists, Swift knows this is no longer an `Optional` value and we are safe to call print with `color`.

There's even a shorthand since this is so commonly done:

```swift
if let color {
    print(color)
}
```

Essentially, _unwrapping_ is a fancy term for asserting that a value exists on the variable. The nice thing about swift as a statically typed language is that it will encourage you to check your values in ambiguous scenarios.

### XCode

XCode has been interesting to use. Unsurprissingly, the typography and design is very Apple. In that sense, it's delightful.

Like any new program, it's easy to be overwhelmed by the sheer number of menus and options to toggle. However, it doesn't take long to find the few options you'll use the most often.

It's a seamless dev experience working with iOS apps here. Unsurprisingly, when the software is designed for a specific platform, it works really well with said platform. Spinning up a simulated app environment is quick and easy. UI wise, you have a couple of options between SwiftUI and UIKit when sticking to Apple support. And adding components from those libraries is as easy as drag-and-drop.

One thing that takes getting used to is a UI interface for adjusting any elements I add to the Storyboard visual editor. When you're used to scanning documentation or skimming through the options in intellisense to find input options, it feels a bit slow and laborious to have to paw through menus to find where I can resize a button element. Perhaps there are other ways of working with elements that are more text driven. Either way, I'm sure it would just take some time to familiarize oneself with where all the menus are.

One of the most interesting features lies in the intersection between Interface Builder elements and the hand written code. Interface Builder is the WYSIWYG style visual pane for adding elements to a view. However, you can connect them to your own custom written swift classes. Doing so even has the nice UI flare of simply dragging and dropping the element into a line of swift code.

```Swift
import UIKit

class DetailViewController: UIViewController {
    // This line was added by dragging and dropping (while holding ctrl)
    // the imageView from the Interface Builder
    @IBOutlet var imageView: UIImageView!
    var selectedPhoto: String?
    var photoTitle: String?

     override func viewDidLoad() {
        super.viewDidLoad()
        title = photoTitle

        if let imageToLoad = selectedImage {
            imageView.image = UIImage(named: imageToLoad)
        }
    }
}
```

There is a certain magic there. Seeing a visual element and being able to hook into it this way.

## Impressions

My assumption was that learning Swift would take a bulk of the on ramp time, and then developing on Apple's platform would be smooth sailing. I found the opposite to be true. Swift, at least at this stage in my tinkering, wasn't event the meat and potatoes of my development. It was largely working with interface building, laying out elements there, and then writing a few lines of swift code to get specific functionality.

Perhaps that's unsurprising at the entry level. But I'll say, since a bulk of the benefit of native development is using native interfaces and components, it makes sense that I don't have to type nearly as much boilerplate or initialization code to get started. So in that sense, the language is not the barrier to entry.

However, gettinng up to speed on platform development _does_ take time here. I've come to find this more true with the more tooling I use. Languages are largely similar in their feature set. The frameworks and platforms, however, all require you to learn their way of developing. It's as true for iOS dev as it is for React. So, when learning this sort of thing, much of the time will be spent here.

Largely, though, once that hurdle is covered, the all-encompassing IDE is a smooth experience. Apple is known for excellent design. So it's nice to know that, out of the box, I'm working with components that are elegant to use.

All in all, a great first impression.


First Impressions from Native iOS Development


A [great write up](https://articles.pragdave.me/p/we-need-a-better-term-than-software) by Dave Thomas on how the title "Software Engineer" simply doesn't cut it when it comes to sucinctly describing what the people in these roles provide:

> [A] good developer can sometimes manage to deliver that value without actually writing a line of code. Developers occupy a unique position in most companies, sitting at the confluence of many business units and their customers. Developers often have a broader picture of how the company works and how things interact that many of the business’ managers. Many times I’ve seen a manager deliver a requirement to a team, only to have the team respond, “we can do that, but why not just…?”
>
> So, if we’re engineering anything, it’s value, not software...
>
> The people who deliver value by iteratively refining software deserve to have a name for what they do. It isn’t programmer, designer, analyst, front-end developer, or software engineer. It’s bigger than that, and it’s more subtle.

A great reminder at a time where the "programming" part is becoming more and more automated in our work. The contribution expands beyond the specific tools used to provide solutions.


Value Engineers


As kids do, I had a niche affinity. Mine was Smooth Jazz. Houston had a great radio station at the time (95.7 — The Wave.) Any wonder why I decided to pick up playing the saxophone?

The Weather Channel, as you can image, only added fuel to the fire of passion. And Trammell Starks was a frequently played artist.

Here's his collection "Music For Local Forecast."

<figure>
<iframe src="https://archive.org/embed/lfset1" frameborder="0" webkitallowfullscreen="true" mozallowfullscreen="true" allowfullscreen className="internet_archive_audio" ></iframe>
<figcaption>[Listen on The Internet Archive](https://archive.org/details/lfset1)</figcaption>
</figure>

Certainly very of the genre. The Pat Metheny influence is unmistakeable. There are moments where it's not so smooth. "Jumpin'" in particular has the pianist _slamming_ on the keyboard! (I wonder if this is Starks himself?)

For more fun: [TWC Classics](https://twcclassics.com/audio/years.html) lists all the songs played on The Weather Channel from 1983-2002. Trammell had [a great showing](https://twcclassics.com/audio/years-1997.html) in '97!


Music For Local Forecast

Lynes – Sonatina in C


![Dancing the night away](https://padilla-media.s3.amazonaws.com/blog/art/sketches-2024-01-27.jpg)

Going to the Parker Winter Formal with soon-to-be Dr. Schultz 💙


Parker Prom

Junkyard Jam


I'm gearing up to get [my music on Spotify](https://open.spotify.com/artist/3KNN2G4RReLVKbnIfTkRFf)! A pretty exciting step!

But I've hit a problem: There are already 3 folks named Chris Padilla on Spotify.

It's not a new problem. In high school, I was one of 5 Chris's that played saxophone.

I'm used to having to mix up my usernames across apps and sites, but this is my whole _name_ we're talking about!

Worth noting: It's not just a musician or an artist concern, it's a professional concern! Even [Wes Bos and Scott Tolinski talked about this on Syntax](https://syntax.fm/show/342/potluck-video-hosting-fake-names-portfolio-projects-monorepos-apis-tlds-recording-tips-more).

I got this advice from [Distrokid](https://support.distrokid.com/hc/en-us/articles/360013534234-Will-It-Cause-Problems-If-There-s-Another-Artist-with-the-Same-Name-as-Me-):

> Ideally, if someone already has the name, you should come up with a different name. In the world of actors, for example, no two actors are allowed to have the same name as each other and both belong to SAG (the actors union). That's why Samuel L. Jackson is Samuel L. Jackson, and not Sam Jackson or Samuel Jackson -- those names were taken. If you want to look like a pro, suck it up and come up with a different name if yours is already taken.

Fair enough. So now I'm in that spot where I'm coming up with a name.

The process so far is somewhere between writing down inspirations, aesthetics I like (colors, themes, the like), and also turning to [a random name generator](https://jimpix.co.uk/words/random-username-generator.asp#results) to see what sticks.

# Benefits of a Stage Name

I've liked being just "Chris Padilla" pretty much everywhere. It's kept things simple and easy for the most part. Even with music, just knowing that it's my solo project and that it can all be pointed back here.

[I'm not the only Chris that does this, either](https://chriscoyier.net/2010/02/25/one/)!

**But.**

There are some exciting opportunities with stage names.

First: A stage name can encapsulate a project. Done with a set of ideas and themes? No problem! Change names and move on! [Prince did it for more contractual terms](https://www.bbc.com/news/magazine-36107590), but it still worked for him!

Second: It brings an opportunity for clarity between those projects. A problem I'm starting to have is that when someone asks "What do you do?" The answer is: Software, music writing, saxophone performing, drawing, blogging, teaching. Potentially, the list could continue to grow over a lifetime! As a human being, that all can be contained within one Chris Padilla. But if you want to talk marketing terms, it gets difficult to say "Chris Padilla — Developer, Musician, Doodler, Internet Guy, Baker of Pies..." and so on.

Third: A healthy dose of separation between "The Real You" and "Public You." [Derek Sivers says this well](https://sive.rs/publicu). I don't have the pleasure of being big enough for strangers on the internet to criticize me, but should I ever be, it's easier to say "Well, they're talking about Chris D Padilla. Not me, just Chris."

Fourth: There's a certain _freedom_ that comes from a stage name. I always felt that by performing on stage, you had a chance to embody a character. To step into a person, mindset, and mood you might not otherwise channel in your day-to-day life. A stage name is just another layer of that. Online, there's no clear stage. But a name can be like putting on a super-suit in that way.

It's funny how some domains don't have that choice. Authors, speakers, most professional work — it's all on your real name for the most part. But I think there is something to be said about how we are separate from the roles we step into.

(Well drat, but that's not entirely true! R.L Stein, Lemony Snicket, Paul Creston — all Pseudonyms!)

# But, Then Again

There's also the benefits of consistency! Unambiguous, less elevated and pretentious feeling, less "webby" (I'm thinking of Twitter handles and gaming tags), more personal, and the benefit of carrying any reputation with you even as you pivot and transition through domains.

Also, maybe this is more of a problem if my name were Chris Martin. There's a _really_ famous Christ Martin already, of course.

And then, on top of that, context matters! If I'm talking about L. Armstrong, you'll know who I mean if I'm in the midst of talking about famous Jazz musicians. You won't confuse Louie Armstrong for Lance Armstrong there.

If we're talking about SEO, a quick search of "Chris Padilla Sax" will pull up my YouTube channel of Sax videos. You won't even be recommended [the Wikipedia page for former Under Secretary for International Trade Christopher A. Padilla](https://en.wikipedia.org/wiki/Christopher_A._Padilla).

So, maybe it's not as much of a problem.


Chris Padilla/Blog

On This Day