(I’m not affiliated with Manning in any way, other than I own some Manning books and get their announcement emails, which is how I found out about this.)
Don’t worry, this isn’t mandatory, but if you’re new to Xcode (or new-ish), you might want to try out this simple app exercise beforehand, just to get comfortable with the tools.
Once you’ve installed Xcode, launch it and follow the steps below. The app you’ll make is simple, but the exercise will get you used to working with the tools.
Create a new project
Open Xcode. From the File menu, select New, then Project.
You’ll see this window pop up:
This window lists templates for the different kinds of projects that you can build using Xcode. Templates are starting points for projects that contain just enough code to actually work, but they do little more than display a blank (or mostly blank) screen.
Make sure that the selected template category near the top of the window is iOS and that App is the selected template. Then click the Next button.
The contents of the window will change to this:
This window lets you choose options for the project you’re creating. For simplicity’s sake, we’ll take the approach you might take if you’d just installed Xcode and don’t have an Apple Developer account. Here’s how you should fill out this screen:
Product Name:My First iOS Project
Team: Select None.
Organization Identifier: Use com.example (or, if you own your own domain, use it, but in reverse — for example, if you own the domain abcde.net, you’d enter net.abcde into this field).
Interface: Go with the default SwiftUI.
Language: Go with the default Swift.
Leave the Use Core Data and Include Tests checkboxes unchecked.
Click the Next button, and you’ll see this:
Select a place to save the project, then click Create.
Xcode now has all the information it needs to build a basic iOS app project. It will build this project and then present the full Xcode interface, as shown below:
The Xcode window has four general areas, which I’ve numbered in the screenshot above:
The Explorer pane. The leftmost pane of the Xcode window contains a set of Explorers, which is a set of menus that let you look at different aspects of your project. The one you’ll probably use most is the Project Explorer, which lists the project’s files and allows you to select the file you want to view or edit.
The Code pane. This is where you’ll read, enter, and edit code. You’ll use this pane a lot.
The Canvas pane. This pane lets you preview what the user interface will look like in real time, as you enter code that defines the it.
The Inspector pane. The rightmost pane lets you get details about any code or user interface element that you currently have selected.
As I said earlier, when you create a new Xcode project, Xcode builds in enough code for a very bare-bones application.
Run the project
Take a look at that application in action — click the Run button (located near the top of the screen; it looks like a ▶️ or “play” button)…
…and Xcode will launch the iOS simulator, which imitates an iOS device. Give it a few seconds to launch, and then you’ll see this:
The app doesn’t do anything other than display a 🌐 icon and the text “Hello, world!” In this exercise, we’ll take this starter app and make it do a little more, adding user interface elements along the way.
The ContentView file
Let’s take a closer look at the code. First, look at the Explorer pane and make sure that ContentView is selected:
ContentView is a file, and the code inside it defines the app’s one and only screen looks and works.
Here’s the code inside ContentView:
struct ContentView: View {
var body: some View {
VStack {
Image(systemName: "globe")
.imageScale(.large)
.foregroundColor(.accentColor)
Text("Hello, world!")
}
.padding()
}
}
struct ContentView_Previews: PreviewProvider {
static var previews: some View {
ContentView()
}
}
Structs
You’ll see that the code is divided into two blocks, each beginning with a keyword: struct, which is short for “structure.” If you’re familiar with object-oriented programming languages like Python or JavaScript, you should think of Swift’s structs as being like classes: they’re “blueprints” for objects, and can have properties and methods.
There are two structs in the ContentView file:
ContentView, which defines what appears on the screen when you run the app.
ContentView_Previews, which displays ContentView in the Canvas pane, allows you to see what ContentView will look like while you’re coding the app.
For now, let’s just look at ContentView.
The ContentView struct
When you create a new iOS app project in Xcode, Xcode creates a “starter” project for an app with a single screen. Xcode gives this screen a default name: ContentView.
The name ContentView is arbitrary. You could rename it MainScreen or HelloWorldDisplay, and it would still work. Many developers change the name of ContentView immediately after they start a new iOS app project, but for this exercise, we’ll just stick with the name.
Let’s take a look at the first line of ContentView:
struct ContentView: View {
The struct ContentView part of the line declares ContentView as a struct.
The : View part says that ContentViewadopts or conforms to the View protocol:
If you’ve programmed in C#, Go, Java, PHP, or Python 3.8 and later, think of a Swift protocol as being similar to an interface.
If you’re not familiar with interfaces but have programmed in an object-oriented programming language like JavaScript or Python prior to version 3.8, think of protocols as a loose form of inheritance.
You can think of the line struct ContentView: View { as saying “This is a struct named ContentView, which includes the properties and methods of a View object.”
Now let’s look at what’s inside ContentView:
var body: some View {
VStack {
Image(systemName: "globe")
.imageScale(.large)
.foregroundColor(.accentColor)
Text("Welcome to the app!")
}
.padding()
}
Pay particular attention to that first line:
var body: some View {
ContentView contains just one thing: a variable. That’s it!
The var body part of the line declares body as a variable.
The : some View part says that body contains some kind of object that adopts the View protocol.
You can think of the line var body: some View { as saying “This is a var named body, which contains some kind of View object.”
The View protocol
The term “view” has a specific meaning in non-web GUI programming. It’s used to refer to any of the following:
A user interface element such as static text, a text field, a button, a switch, an image, and so on, or
A container for other user interface elements.
Here’s the code for ContentView and the resulting screen that shows the connections between the code and the views it creates:
ContentView is a plain View. It functions as the app’s one and only screen, and it contains that screen’s views.
Inside the ContentView is a VStack, which is a kind of View whose name is short for “vertical stack.” Like ContentView, VStack is a view that contains other views, but the views it contains are arranged in…you guessed it: a vertical stack or column.
Inside the VStack are two other views whose purposes you can get from their names:
Image: This view displays images.
Text: This view displays static text — the kind that the user can’t edit.
All of these things listed above adopt the View protocol, which means:
They are either a user interface element or a container for user interface elements, and
They include the properties and methods of a View object.
Let’s talk about that second point: that in order to adopt the View protocol (or more loosely, to be a kind of View), a struct includes the properties and methods of a View object.
There’s only one required property an object needs to adopt the View protocol: it just needs to have a variable named body, whose type is some View. body is a property that contains some kind of user interface element or a container for user interface elements.
In the case of ContentView, which adopts the View protocol, its body property contains a VStack. That VStack contains an Image view and a Text view.
The Text view
Let’s play around with the Text view first. Find the line inside ContentView that looks like this:
Text("Hello, world!")
And change it to this:
Text("Welcome to the app!")
You should see the preview in the Canvas pane update to match the change you made:
If for some reason the preview didn’t update, look for the text “Preview paused” at the top of the preview and click the “refresh” icon to “un-pause” it:
Add a new line after the Text:
Text("Good to see you.")
This should add a new Text view to ContentView, and Xcode’s preview should update to reflect the change:
Run the app. The preview will pause and the Simulator will start up and launch the app, which will look like this:
Notice that running the app in the Simulator pauses the preview. Running the app in the Simulator or making big changes to the code causes the preview to pause, but you can always restart it by either:
Clicking on the “refresh” icon at the top of the preview, or
Using the keyboard shortcut command + option + p
Text view modifiers
Let’s make the “Welcome to the app!” message on the screen larger — it should be the size of a title. Do this by changing the line that creates that Text view to the following:
Text("Welcome to the app!").font(Font.title)
Run the app or restart the preview — it should look like this:
I’ll cover more in Monday’s session, but feel free to experiment!
Let’s hear it for the “meatier” meetups — the ones where the event isn’t a meet-and-greet, but an actual technical presentation with ideas, concepts, and maybe even code that you can then use in your own work or personal projects. They don’t get the “draw” that a meet-and-greet does, but they are vital. (Someday, I’ll tell you the story of how technical meetups forever changed the Toronto tech scene.)
Developers have many options for building applications today, not just for what programming platform to use, but also what architectures are possible. Modern applications can be built using everything from monoliths to microservices to cloud functions.
In this session, we’ll look at serverless architecture for building applications and compare them with the other models. Historical problems with long cold-starts, heavy-weight frameworks and lack of tooling have made Java an unpopular choice for serverless development… until now!
We’ll take you on a journey to explain what has changed with Java to finally make it an amazing language for building serverless applications. We’ll do demos of Java Cloud Functions deployed on AWS, Azure, and GCP. We’ll also look at tips for building Java Cloud Functions including:
☕️ JVM ☕️ Advances in the JVM like CRAC ☕️ Low-overhead, serverless ready frameworks ☕️ Where AOT (ahead of time) compilation ☕️ Right-sizing Java Cloud Functions
The speaker, Pratik Patel, is a Java Champion and developer advocate at Azul Systems. He wrote the first book on ‘enterprise Java’ in 1996, “Java Database Programming with JDBC.” An all around software and hardware enthusiast with experience in the healthcare, telecom, financial services, and startup sectors. Helps to organize the Atlanta Java User Group, frequent speaker at tech events, and master builder of nachos.
Want to find or more or attend? Visit either of these Meetup pages:
If you want to learn Python, machine learning, data science, and a few other related topics AND you have $25 handy, The Complete Python Mega Bundle has you covered, as you can see from the list of tutorials below:
On Friday, June 23rd at 1:00 p.m., University of South Florida (USF) is hosting an online information session about their Pathway to Computing graduate certificate. It’s a step towards getting a graduate degree — completing this program earns you priority admission to USF’s master’s degree in computer science program with no GRE required.
If you’re interested in getting a graduate degree in computer science, but have never taken a computer science course or don’t have coding experience, but want to start a coding career, this program is for you!
You might know how to program in a high-level language like JavaScript, Python, PHP, and so on, but do you know what’s happening at the machine level? Have you wondered what pointers and references actually are, or the difference between the stack and the heap, and for that matter, what a “stack overflow” is?
Would anyone be interested in a meetup seminar or two where I explain how your computer works “under the hood,” and maybe even walk you through a little programming at the chip level with hands-on exercises? Let me know.
What might the next decade of software development look like? Richard Campbell has some ideas and shares them in this talk from the 2023 edition of the NDC London conference.
Here’s the video:
I know Richard from my former life at Microsoft. He’s the host of the .NET Rocks and RunAs Radio podcasts, and long-time developer, consultant, and tech company founder, and a damn good storyteller.
The first story he tells is about “The Animal Highway,” the space between his and his neighbors’ house, which is frequented by bears. This actually made me laugh out loud, since when I last saw Richard at a backyard barbecue at his house, we had to scare away a bear cub by being noisy. He picked up a pot and barbecue tongs, I picked up my accordion, and with whoops, hollers, and random squeezebox chords, we chased it away into the woods.
One of the themes that runs through his talk is that technology has grown in leaps and bounds. Near the start of the talk, he uses the example of the Cray X-MP. In 1985, it was the world’s most powerful computer. It sold for millions of dollars and required 200kW of power, which could perform 1.9 at gigaflops (billions of floating-point operations per second). It was used to model nuclear explosions and compute spaceflight trajectories.
The iPad 2 from 2011 also performs at 1.9 gigaflops, but it sold for hundreds of dollars instead of millions, and ran on battery power instead of requiring its own power plant. As Richard summed it up: “26 years later, the most powerful computer in the world is now a device we give to children. And they play Candy Crush on it.”
Near the end of the talk, Richard uses another example of the technological changes that have happened in a lifetime. The picture above shows the first transistor ever, which was made in Bell Labs in 1947.
“It’s pretty hard to look at that,” he said, pointing to the photo of that transistor, “and think ‘M1 chip’.”
In case you were wondering, here’s how many transistors the different variations of the M1 chip have:
Chip version
Number of transistors
M1 (original version)
16 billion
M1 Pro
33.7 billion
M1 Max
57 billion
M1 Ultra
114 billion
If you want an understanding of how we got to the current state of computing and some good ideas of where it might go, Richard’s talk is not only enlightening, but also entertaining. I listened to it on this morning’s bike ride, and you might find it good listening during your workout, chores, commute or downtime.