As an Indie App Developer, Marketing Terrifies Me

I’ve been working on an app for over 2 years now, and I feel like I’ve done a fair amount of research about how to market an app. Enough to know that I really don’t know how to do it. My chances of launching an app that anyone will download, much less pay for (through in-app purchases, my chosen monetization method), is slim. If you’ve done any research about common ways that apps fail, probably the most common is that the marketing didn’t connect with users, or there wasn’t any marketing done at all.

If you just build it, they definitely won’t come

It seems like there’s a fair amount of indie app developers with no marketing plan at all. No matter how great an idea, no matter how well an app solves a problem, if nobody knows about it they won’t be downloading your app. I think every developer would like to think their app is going to be the next Instagram – it’s so awesome that it simply markets itself.

The truth is, no app markets itself. And the version of Instagram in your head where it was so cool and awesome that no one had to do any marketing is simply an illusion. If you look into how Instagram was created, they had to do a lot of hard work and big changes to get anyone to be interested in it.

For my app, I know if I don’t have at least some kind of plan to market it, I’ll fall into that group of apps that good or bad, never get discovered.

App store optimization – does it do anything?

I understand App Store Optimization (ASO) to be the technique of trying to get your app to come up in search results when users search on the App Store. There are ways that ASO can be quickly applied, for example choosing the correct wording for the title of your app, as well as writing a good description with good screenshots.

But the more effective ASO techniques require hard work, diligence, and time. The app store wants to see, for example, that your app has lots of good reviews, that your app is updated often, and has a lot of downloads before it really starts showing your app in search results.

This presents us a chicken-and-egg scenario. How do you get good reviews and downloads if the App Store wants you to already have good reviews and downloads? I’m thinking that the answer is that ASO is not a good marketing technique by itself. There’s no special words or key phrases you can put in your app’s description that’s going to magically attract users to it. That may have been true early on in the history of the App Store when there weren’t so many apps and app developers. But now there’s lots of competition, and you really have to stand out from the crowd.

How to stand out?

If app marketing takes time and hard work, how do really successful apps launch themselves to popularity within a few days or weeks of launch? That kind of rocket-propelled launch doesn’t happen by accident. It’s almost always part of a carefully planned marketing campaign, using a number of techniques to draw attention to the app’s existence.

I think it’s safe to say that this marketing business is no easy task all by my lonesome, especially when most of my time is spent, you know, building the app. I need some help.

My plan

My plan has two parts:

  1. Do my own social media marketing
  2. Try to get someone with some influence to help

That’s about it. The other person on my team, my wife, has a Youtube channel (https://www.youtube.com/channel/UCfms-4LkhJ3oR2Y4GbUy1xw, if you’re interested) an Instagram account, and a Facebook page, and we’re going to market the app there.

For my part, I plan to spend a few months to do some groundwork trying reaching out to some influencers that might be interested in promoting my app, and see what they want in return.

We’ll see what happens! Wish me luck!

No Need To Be Afraid – iOS Apps Are Just Loops

I’m pretty sure that most beginning programmers are intimidated by the term “loop”. After all, a loop in real life could mean a number of different things that bear little similarity to the concept of loop in computer programming. I was recently talking with an aspiring iOS developer that was struggling with how a button is linked to Swift code in iOS.

As we continued the discussion, I realized that what was clear to me from experience writing code wasn’t clear to the person I was talking to. What is happening in the background when you load an app? Well, quite a bit, actually. And it isn’t really stated clearly off that bat when you jump into Xcode and iOS development. Sure, it’s probably in the Apple documentation somewhere, but it’s not spelled out for you.

The main event loop

You’ve probably been told that computer code is just a bunch of instructions that tells the computer what to do. The computer executes your commands to a tee. By that logic, the computer should run your commands until it has no more commands to execute, and stop. Right?

Well, yes. But remember Apple did some stuff in the background that you can’t see. So if you just write a couple of print statements in viewDidLoad (the first function to run in your app) in your app’s only UIViewController (the thing that shows the app’s view on the phone’s screen), what exactly is your app doing when you run it? How is it still running and showing something on the screen after the code you wrote has been executed?

The answer is that your app, at it’s most basic function, is a loop. By loop I mean it goes in a circle, doing the same things over and over. Specifically, it does two things in this loop. It checks for an “event” – a good example is whether or not the user tapped a button. The second thing is it reacts to an event if one happened. A good example would be to play a sound in reaction to a button being tapped. If no event happened, it checks again. And again and again, in a loop. That’s what your app is. In my head, it looks a little something like this:

Apple does in fact have official documentation on this subject, it’s really old and in their archive but doesn’t seem to have been replaced by anything new. So as of this writing at the end of 2021, Apple’s explanation of the iOS app main event loop is here, I thought it would be worth mentioning:

https://developer.apple.com/library/archive/documentation/General/Conceptual/Devpedia-CocoaApp/MainEventLoop.html

Your app’s job: react to events

Back to computers executing commands one by one – yes that is how they work. A computer program that works in this fashion is loosely called a “script”, but there’s no hard definition of what that actually means. The important thing to remember about the difference between your app and other types of computer programs is that it’s waiting for input from the user, who is (hopefully) the owner of the phone your app is running on. Your app’s job is to react to input from your user.

So how does the iPhone know what code to run when an event happens? It knows because you tell it. You attach a function to a button, which is just a bundle of code. That function will run when the button is pressed. The cool part is iOS does all the heavy lifting for your once you make the connection. You don’t need to know about how messages are carried in the event loop or what’s going on behind the curtains, just connect your button and code and away you go! It almost feels like you’re cheating somehow.

Happy coding!

Swift Classes vs. Structs – Why You Shouldn’t Care About The Difference

Like all iOS developers at some point early in their app-building journey, you may be wondering what the difference is, when to use one over the other, and why you should care. If you’re at this point, especially if you’re new to programming, I’d highly recommend not caring. That view might make the Internet mad, but after learning the major differences and reading the Apple documentation, I would still make that recommendation. If you’re an experienced developer, you’ve already made your decision and not only done the research, you understood what you were reading. But for the rest of us non-super geniuses, classes and structs can be a pretty abstract concept that’s hard to wrap your head around. In the end, I think you can build a basic app using either one, and until your app’s performance is hindered by the improper use of one or the other, why not just focus on more pressing matters?

They both do the same thing

This isn’t entirely true, and under the hood they’re fundamentally different, but if you’re at a point where you need to create a custom object – just pick one and move on. The first time I found I was really forced to create my own object was when I needed to read and write JSON. The hippest coolest way to deal with JSON these days in Swift is to use the Codable protocol. The only issue is both structs and classes can do the codable thing:

struct JamesStruct: Codable {
    var key:String = "value"
}

class JamesClass: Codable {
    var key:String = "value"
}

So which one to use, then? The StackOverflow example I found somewhere and mercilessly copy/pasted used a struct, so I just went with that without really understanding why. Is that so wrong? I mean come on, we’ve all done it. Even the most advanced, highly-paid, successful and super genius developers out there have quickly scraped StackOverflow because they were on a deadline. Anyone who says otherwise is likely selling something.

You need context to really understand the difference

I always need some sort of context to really understand how something works. Sure I could conjure up some pie-in-the sky example for you to illustrate the differences between these two, but there’s a zillion blogs out there already that have done that for you. Not to mention if you’re looking for pie in the proverbial sky, the official Apple guidance on the topic is here:

https://developer.apple.com/documentation/swift/choosing_between_structures_and_classes

I could say that classes are a reference type and structs are a value type, that structs are “lightweight” and classes are “heavier”, or that only classes can inherit. But it probably doesn’t mean much to you unless it specifically affects YOUR app and YOUR use case somehow.

If you’re debating which one to use in your app, or wondering if you used them correctly, why not just play around a bit? See what happens when you substitute one for the other. That’s where you’ll really learn.

If you need a hard recommendation, Apple says default to structs

If you checked out the official Apple guidance, you might have noticed they said to use structs (as of this writing, end of 2021) unless you have a specific reason to use classes. Which brings me to the image at the start of my post – I was surprised to learn that many of the basic data types in Swift like Strings and Int’s are, in fact, structs. If Apple is using them in that capacity I think it’s safe to say your custom object is mostly likely a good candidate for a struct.

Happy coding!

Swift Classes – You Don’t Really Need To Understand Them.

Of course, that’s not actually true. If you want to become an expert Swift programmer, you absolutely need to understand classes. However, I believe you don’t really need to know that much about classes to get going with them. In fact, the first time you use them you probably won’t even really be aware of it other than there’s a “class” keyword in your code at the top.

Tutorials might have confused you.

At least, I was confused. Most of the explanations I read/watched about classes went something like this:

“A class lets you create a custom object. For example, say you wanted to create an Animal class, you’d do it like this:”

class Animal {
 let greeting = "I am an animal"
}

“Now you can create multiple Animal instances from the original design you created in Animal, like this:”

let animal1 = Animal()
let animal2 = Animal()
let animal3 = Animal()

“Now create a subclass, that lets you use all of the stuff Animal had, and customize further for this subclass. Our subclass will be Dog:”

class Dog: Animal {
 let species = "I am specifically a dog"
}

“And now you can create as many Dogs as you want, an army of them in fact, all with the powers of both Animal and Dog:”

let myDog1 = Dog()
let myDog2 = Dog()
let myDog3 = Dog()

print("\(myDog1.greeting). \(myDog1.species)")
print("\(myDog2.greeting). \(myDog2.species)")
print("\(myDog3.greeting). \(myDog3.species)")

And the tutorial would go on to explain properties, methods, etc. That’s super cool, and those are indeed the magical powers of classes and object oriented programming. When I first saw this kind of explanation, the concept totally made sense in my head. I was totally on board with the logic.

But how to use them?

But then I went to try and write an app of my own, and found I had no idea why anyone would ever use classes in actual code. Sure it’s all fun with animals, dogs and cats, but I was way more concerned about how I would get my app to show an image or a button, for starters. That’s the level I was at. But there was the class keyword staring at me when I created a new project in Xcode, without ever writing a single line of code on my own. It appears in the freebie stuff Xcode gives you when you create a fresh storyboard-based project:

class ViewController: UIViewController {

    override func viewDidLoad() {
        super.viewDidLoad()
        // Do any additional setup after loading the view.
    }
}

Why is class there? And it’s not just a class, it’s a subclass. To be honest, understanding why isn’t really necessary to get your app to fire up for the first time, or to get an image on the screen, or put some basic logic behind a button.

I’ve realized that to create a basic app, you don’t need to worry about creating classes from scratch, or much less create subclasses of your custom classes to use abstract object oriented constructs such as polymorphism or multiple inheritance. The most immediately applicable use of a class is right there in that first bit of code that Xcode populates for you.

There’s a swift class right front of you

If you think about what the Apple developers might have been thinking when they were cooking up Xcode, they can’t possibly know what your app is going to do. At some point, they have to hand some control of the screen to your app. The way they accomplished this was to create UIViewController, which does a bunch of stuff you can’t see to create a blank screen on the phone, ready to be customized for some interesting and unique things your app will do. If you don’t customize UIViewController, all your app will ever be is a blank screen. By creating a subclass of UIViewController (Apple assumes you want to call this ViewController), you can now write your own custom stuff to show beautiful things on the screen. You don’t really realize it, but you’re using inheritance.

The subclassing in this line lets you customize the view:

class ViewController: UIViewController

But where does the handoff take place? When does Apple hand off the view to your app? As it turns out, viewDidLoad() is a function that Apple already wrote. Like the name suggests, it loads up the view. But if you don’t customize it, it’ll just be a blank view of nothing. That’s why you need to “override” viewDidLoad to customize it, so you can start running your own code. That’s what’s happening here:

override func viewDidLoad()

But there’s one last thing to do in your now-overridden viewDidLoad function. Since you overrode it, the original Apple code to load up the blank view won’t run. So you have to run it with:

super.viewDidLoad()

At this point, you’re finally ready to write your own custom code for your app.

As you keep coding, you’ll realize that subclassing Apple-created classes like this is really helpful when you want to do all sorts of things, and the inheritance concept will make a very real-world kind of sense.

I really think that’s a more realistic approach than an Animal/Dog/Cat example of classes, which makes sense after you’ve had a lot of experience.

I hope that helps! Happy coding!

Optionals – The Pyramid of Doom

If you’ve figured out how to deal with optionals using optional binding (check out my post on how to deal with them in a simpler way if you’re lost) you might have started wondering what would happen if you had to unwrap a really long list of optionals. Well, what happens is exactly what you think would happen, it becomes a giant pyramid of doom.

let optional1:String? = "optional1"
let optional2:String? = "optional2"
let optional3:String? = "optional3"

if let one = optional1 {
    if let two = optional2 {
        if let three = optional3 {
            print("\(one), \(two), and \(three) are unwrapped.")
        }
    }
}

Add more optional variables, and your pyramid just gets bigger.

How to avoid with guard

Swift came out with a keyword in Swift 2.0 called “guard” that works the exact opposite of “if let”. You can keep your unwrapped variable outside of a code block and avoid a cascade of curly braces. Assuming you’re using it inside a function, you can just return from the function if the optional is, in fact, nil. Otherwise you need to throw an error or somehow leave the current code block (scope) that your code is running in:

guard let one = optional1 else {
    return
}

guard let two = optional2 else {
    return
}

guard let three = optional3 else {
    return
}

I find guard a bit hard to work with since you have to have return or throw. It also took me a while to really grasp what was going on with it. If you’re like I was when I was first dealing with the pyramid of doom, it might help to have an alternative option.

Another option

No pun intended. Why not just check if they’re nil with if? It’s not against the rules. It just seems like most examples out there show the Swifty, Appley ways of handling optionals like guard, binding, chaining, and coalescing. They certainly are very appealing to the eye, and perhaps more efficient. But hey here’s another option that might help: check them all in a chain of “or” statements. All the variables need to be unwrapped anyway right? The code of interest is at the bottom of the pyramid, which means all variables need to be not nil for that code to run.:

if 
 optional1 == nil ||
 optional2 == nil ||
 optional3 == nil {
 //Do something to handle nil. Maybe put below code in "else". Idk.
}
 
let one = optional1!
let two = optional2!
let three = optional3!

print("\(one), \(two), and \(three) are unwrapped.")

It’s not perfect, but I think it’s more readable, understandable and usable for a beginner like I was (am). It also doesn’t take you to your doom. It’s similar to another solution called “early return”, but I think mine is a little different because it only uses one “if”.

Happy coding!

Optionals – A Snag For Every Swift Beginner

Why would something ever be “optional”?

How quickly you grasp the concept of optionals will probably depend entirely on what background you come from. If you have no programming background, you’ll probably be faced with the same question posed by all the other programming concepts you’ve learned, such as variables, functions, loops etc. How is any of this useful? Why would anyone use it? For seasoned programmers in multiple languages, you probably picked it up right away. I came from several years of Python experience, which did very little to prepare me for the concept of optionals. I was put right back to my beginning programming days wondering why anyone would ever need to use such a thing, or how it would ever be considered “powerful”. From various tutorials, I was able to understand the optional concept, but didn’t know how or when I would be using them. So I just started coding. I wasn’t creating my own optionals at all, I didn’t see any reason to. But almost immediately, I came across optionals given to me by the various pre-built things in UIKit (Apple creates these things for developers to build a visual interface, they include UIButton, UITextField, UILabel, etc), and I was struggling with how to get data I wanted inside the optional. Swift won’t let you move on if you don’t deal (handle) with the optional.

Sure, I know about optional handling.

If you’ve done a Swift tutorial, they’ve probably told you the different ways of “handling” an optional. If you’re looking at an optional data type right now, you might have no idea how to get it open properly or why you would choose any one of the different handling options. But in order to pick which one to use, you really need to see them in action before you really can make an informed and intelligent decision. So instead of trying to completely grasp how to use optionals like a pro before ever using them (which makes no sense, when you really think about it), just do the easiest one, it’s called a “Force Unwrap”. You put an exclamation point at the end of the optional to “unwrap” it and get whatever’s inside, in this simple example it’s a string:

let myOptional:String? = "this is the string inside my optional."
let myString = myOptional!

If you’re new to optionals, just use this one. Yes, it’s “dangerous”, a word that requires a grasp of the concept of optionals to understand, but it’ll get at the data you want and you can move on with your coding. “Dangerous” would be if you had released your app on the App Store to real people, and you used this method of optional handling everywhere in your app. But let’s be real – if you’re wondering how to do the optional thing, like I was, you’re nowhere near releasing your app to the App Store. Just live life simply and dangerously, and use Force Unwrapping. Starting with the simplest and easiest option to understand will let you get your feet wet with them, and you’ll eventually see why you need the other options.

The nothing problem

It took me a long time to grasp the idea of the problem of nothing, or nil in Swift, for programming languages. Starting with a “high-level” language like Python, so much is handled for you in the background with features like garbage collection and dynamic data typing. What I came to realize was that when you’re building your app, you’ll reach a point where you do something that may get the result you wanted, or it may not. A lot of times the in the “may not” scenario, the result will be placed in an optional and the contents will be “nil”. For instance, building on the example above, let’s say you had a login screen and you wanted to get the user’s email address in order to log in. You might have a text field to allow the user to type their email address.

let myTextField = UITextField()
let myString = myTextField.text!
login(with: myString) //Not a real function. it just illustrates my point.

As it turns out, the “text” property of a UITextField, which should contain text the user typed, is an optional string. To unwrap it, put a “!” at the end of it. Then log the user in with the fictional “login” function (pseucode, as it’s called). Why an optional? Why not just make it a string and make it easier for everyone? The answer is because you have no idea what the user is going to put, or not put, in that field. It could be something, it could be nothing. But if you just use a Force Unwrap, and test logging in without typing anything in your field, your app crashes, saying something about unexpectedly getting nil. That’s the crux of the problem that optionals solve. Computers don’t like nothing. Apparently in some older languages there are not elegant tools such as optionals for dealing with nothing, and applications just crash a lot (a gross oversimplification, sorry to any programmers in said older languages). An optional allows you to deal with the nothing and prevent a crash.

Dealing with nothing

If your app is crashing when you get text from a text field, and you don’t want it to crash and you would rather tell the user, “Hey, please don’t put nothing in this field!”, that’s a good time to use a different optional handling method. There are several other methods, but I’m not going to explain them all, because you just need to work with them to understand. The Internet might get mad at me, because it seems like this is where most people introduce optional binding, which I found to be really difficult to understand. But I think this method, while really wordy, makes it clear what is happening, and keep your app from crashing:

let myTextField = UITextField()
if myTextField.text == nil {
    tellUserToTryAgain()  //Not a real function. it just illustrates my point.
}else{
    let myString = myTextField.text!
    login(with: myString) //Also not real. See above about my point.
}

If you understand “if” in Swift, and you can just check the text in the text field to see if it’s nil, like I did above. If it is, I again used a fictional function “tellUserToTryAgain”, to tell the user not to login with nothing. If myTextField.text does indeed contain text, we can “safely” Force Unwrap it, and grab the text, and use my fictional “login” function to login.

Advanced optionals

Everything else for handling optionals would fall into a category of handling options that I would consider advanced. Once you have spent a significant amount of time working with optionals, you can consider Optional Binding, Optional Chaining and Nil Coalescing. They solve more abstract problems, and I really think you have to work with optionals on a really basic level for a while before you get the use cases for the advanced stuff. At least I did, and unlike most programmers I’m not a super genius so stuff takes a while to sink in.

Happy programming!

Building a Backend, and Realizing I shouldn’t.

I’m hoping my app will make a million bucks at some point. If you’re here hoping to do the same, I’d recommend this book I’m reading – App Secrets: How to Make a Million Dollar App. (Affiliate Link)

Most apps these days have a “backend”, which is usually a server in the “cloud”, usually on AWS, Google Cloud or some other cloud provider where you hold your app’s data, and allow users of the app to access it. Here you can store things like images, user data, analytics info, and allow users to connect with each other, and many other things that will allow amazing types of functionality in your app that would otherwise be pretty much impossible without a backend.

I’m not a web programmer and though I’ve worked with different API’s I’ve never built one myself. This is usually where I head over to Udemy, and find a course on whatever it is I’m trying to learn so I can avoid as many newbie pitfalls as possible and waste as little time as possible. I landed on this course, which is really good:

REST APIs with Flask and Python

If you’re into Python, this one is great. It goes over the basic Python you need to get going, creating a basic API with Flask, securing it, putting data in a proper SQL database, and more. If you need to build an API from scratch I’d highly recommend it.

From Scratch – Only If It’s Your Special Sauce

I realized I wasn’t really excited about building the backend. As much as I like writing code and learning new things, what I really wanted to have was just a basic cloud component for my app to securely store data. You’d be surprised how much is involved with just that. But I figured building the backend was just a necessary component if I wanted to make a cool app, and I needed to get it done so I could get to part I was really interested in – actually building the app.

There are many tools to make developers’ lives easier for certain tasks, for example Flask is a web framework for Python that makes creating a basic API a matter of a few lines of code compared to fully implementing HTTP message handling all by yourself. As far as servers – it’s never been easier to spin up an inexpensive virtual machine in Amazon Web Services, compared to buying a huge expensive server and renting space in a co-location provider like Rackspace, and mounting/configuring it yourself.

But I honestly found myself downright scared to implement things like authentication and encryption, after all I’d being storing user data. The last thing I’d need while trying to attract users to my app was a data breach or my server getting hacked. I began realizing that my special sauce – the app and its content, had very little to do with backend building. Obviously I needed a backend, but at any point during building something you should be asking yourself if somebody already has the component you’re working on figured out already. Especially if you’re working with limited time and resources, any opportunity to save time/effort/money/cycles should be taken. I was around halfway through the above Udemy course when I stumbled onto a service for iPhone developers – Apple CloudKit.

MBaaS – Mobile Backend-as-a-Service

Working in technology I should have known. Anytime developers find themselves building the same thing repeatedly, services crop up to offer it as a service to allow developers to get back to whatever their core competency is. In my case, that’s building my app.

Apple’s CloudKit looked nice, but it’s only for iOS and Apple services, of course. Naturally I wanted to find out if anybody else was offering a similar service but with Android support, and since I use Google services in my personal life quite I bit, I did some searching. It didn’t take long to find Firebase, a Mobile Backend-as-a-Service company started in 2011 and acquired by Google in 2014.

Firebase had all my boxes checked – encryption and authentication are handled entirely behind the scenes, there are SDK’s for both iOS and Android, there is a Python (and many others) administrative SDK, and to top it off it’s completely free to get started and test your app. Not to mention the web-based console is super cool:

The documentation for Firebase is extensive and easy to read. Getting a Firebase “Hello World!” app up and running took no time at all. There’s also a vast user base, and there are many questions posted and answered on good old StackOverflow.com. I promise I’m not affiliated with Google or Firebase in anyway, my mind was simply blown by how easy and awesome Firebase is to use.

After switching to Firebase for my backend, I saved myself loads of time, learning and development effort. I was able to quickly start working on my app instead of building a backend, which I was really not looking forward to. If you’re working alone or on a very small team, this might be something you should seriously consider.

Getting Started with iOS – Online Swift Playground and tutorialspoint.com

I’m hoping my app will make a million bucks at some point. If you’re here hoping to do the same, I’d recommend this book I’m reading – App Secrets: How to Make a Million Dollar App.

I use affiliate links on this site, commissions support my app efforts!

The place to get started developing an app for an iOS device is undoubtedly with Xcode, Apple’s mandated IDE for developing code to run on an iPhone or iPad. You can test your code on a virtual or physical iOS device, publish to the App Store, and some other third amazing thing that for some reason I can’t think of right now. In short, Xcode is your friend, whether you like it or not.

Xcode is only available on MacBooks and my MacBook is on order and will arrive in a week (or two!!). I wanted to get started before it arrives, but the Udemy course I’m taking already wants me to jump into Xcode so that’s no help… I decided to turn to an old friend, tutorialspoint.com. The idea of the site is pretty simple, it’s just a bunch of coding tutorials. The tutorials are sometimes written in poor English,and occasionally struggle to provide real-world examples. However the lessons are quick, to-the-point and I find the quality is similar to McDonald’s – you don’t go to McDonald’s because it’s the best burger, you go because you know exactly what you’ll get.

I like the simple layout – on the left are all the sections like variables, classes, functions, etc. with the content for the current lesson on the right. I can finish most of the lessons in 15 – 20 minutes, which makes for a great way to break down the whole thing into manageable parts. If I don’t understand something either because of the poor English or poor example, I simply take note and move on. I can always look it up somewhere else later.

Where to Run My Swift Code?

I was left with a major question – where would I run my code? There are a few hackable options, such as Macincloud and Hackintosh, but I wanted something that was quick, free, and wouldn’t have to create an account or sacrifice a physical machine. I stumbled on an awesome site – online.swiftplayground.run.

It’s REALLY easy to try out Swift code at this site. You simply go to the site, click “Let’s play” and start coding. If you are waiting for your Mac device to arrive and can’t wait to get started (literally), this is a great option. A “hello world” program in Swift is pretty easy, the “import Foundation” statement was already put in there for me:

Happy coding!

Getting Started – Android Studio 3.2

I’m hoping my app will make a million bucks at some point. If you’re here hoping to do the same, I’d recommend this book I’m reading – App Secrets: How to Make a Million Dollar App.

I use affiliate links on this site, commissions support my app efforts!

My first goal in getting going with any coding project is to get the basic environment set up, which will be key to the next step – the “Hello World” program. This can be a little trickier than it sounds with some environments, but with Android Studio, it was actually incredibly easy, even on Ubuntu Linux.

In case you’re using Microsoft Windows, the process is the same as Linux except in usual Windows cadence. Head on over to Android Studio Downloads and you’ll find a the Windows installer there.

I currently use Ubuntu 18.04 Desktop, and the Ubuntu Store has the latest version of Android Studio, 3.2. I just searched for “Android Studio” and it came right up:

Ubuntu 18.04 Store search results for “Android Studio”

Installing was as easy as clicking “install”. After it finished, clicking “Launch” put me through some initial prompts:

The cool Android Studio splash screen.

Where I get to a welcome screen:

Select “standard”:

And after a screen on theme and settings verification, I’m done:

The installer goes through some downloading and unzipping:

And I’m finished:

I’m then prompted to start a new project or open an existing one, so I start a new one:

And select “empty activity”:

On the project configuration page the only thing I changed was the language to “Java”, per reasons I listed on my About page:

Once everything loaded (it will take a bit) my interface looked like this:

Next up, Hello World!