43: Tips for Building iOS Apps
Published August 18, 2020Run time: 00:33:13
The Jed Mahonis Group has been building mobile apps since 2012, and we’ve tripped over many hurdles when launching iOS apps. Tim and Rob share their tricks of the trade for building apps specifically for iOS, so you can learn from our mistakes and successfully navigate Apple’s unique roadblocks. (And if you’re looking to build an Android app, our next episode has you covered.)
In this episode, you will learn:
- What a DUNS number is
- How to be a good steward of your users’ data
- What to expect to pay Apple in annual fees
- What hardware is needed for building and testing iOS apps
- Why you shouldn’t install beta software on your primary phone
- Why you should be familiar with Apple’s review guidelines before building your app
- How many iOS versions your app should support
- How the TestFlight app works for testing your app yourself and with your users
- What developer tools you can expect to interface with
- Why you should use a task manager for organizing new feature requests
- What the difference is between enterprise and App Store distribution
- How App Store Connect’s two factor authentication can cause delays in deployment
This episode is brought to you by The Jed Mahonis Group, where we make sense of mobile app development with our non-technical approach to building custom mobile software solutions. Learn more at https://jmg.mn.
Recorded August 13, 2020 | Edited by Jordan Daoust | Produced by Jenny Karkowski
Show Notes:
Episode Transcript:
Tim Bornholdt 0:00
Welcome to Constant Variables, a podcast where we take a non-technical look at all things technical. I'm Tim Bornholdt.
Rob Bentley 0:06
And I'm Rob Bentley. Let's get nerdy. What are we talking about today?
Tim Bornholdt 0:25
Well, second take's the charm. We nailed it on that one.
Rob Bentley 0:27
Yes, we did.
Tim Bornholdt 0:30
So as you can hear, Rob's back on the show with us. And today, we are going to cover some tricks of the trade and just general things we've learned over the last eight years of building iOS apps. So you know, we've built software; it's used by millions of people around the world. And, you know, we kind of know what we're talking about. Right, Rob?
Rob Bentley 0:47
Yeah. On a worldwide basis, I'd say we do.
Tim Bornholdt 0:49
Yeah. So we thought we'd kind of give you some of that knowledge and help you stand on our shoulders so that you don't make a lot of the same mistakes that we've made or learned a lot of the lessons you got to learn when you're doing this for a living. So now one thing we want to get out of the way right away is, we mostly just do native app development, not hybrid app development. And we can get into the weeds of what that means. But basically, if you're trying to do things with React Native where you're trying to write your code one place, and then run it everywhere, you know, we don't really do that kind of stuff at the JMG. We do native app development, where we write it specifically for iOS. So you know, a lot of these tips will apply either way, whether you're doing hybrid or native, but just so you know, we're coming from that native development background.
Rob Bentley 1:36
Right, the native versus hybrid could be an episode all to itself, but Apple, either way you're doing that, there's just a few certain things with Apple that are very unique to deploying an iOS app. So we wanted to go over some tips so you can navigate that successfully.
Tim Bornholdt 1:53
Yeah, so let's just jump right in. So our first tip is get your DUNS number early.
Rob Bentley 2:00
So what is DUNS? Yeah. That was my first question.
Tim Bornholdt 2:05
So when you go to create an account with Apple for a developer account, you have to have a developer account in order to have an App Store account, which is so you can list your app on the store. And you can list it in one of two ways. You can either list it as an individual or as a business. If you list it as an individual, then it just shows your name. So it would say, like, my app by Tim Bornholdt. Where if you're running it for your business, you might want to say my app by such and such Corporation. Well, if you want to have a business account on the App Store, you need to verify that your business actually exists. And for some God awful reason, Apple has chosen that you have to go through Brad and Dunstreet, which is like a... Do you even know what they do, Rob?
Rob Bentley 2:46
I think it's credit agency for businesses.
Tim Bornholdt 2:49
Yeah, that's right. It's basically, if you think of Equifax, it's kind of like that, but for businesses and they make you apply for a DUNS number, so then Apple can verify that you're a legit business. And seriously the process has, in some cases, it's taken us six months, seven months to get a DUNS number for a client because there's just so much back and forth on it. So if you're a new startup kind of entity, you'll want to apply for a DUNS number early and just don't do any of the... They'll try to sell you on stuff. Just get your number and get out, right?
Rob Bentley 3:24
Yep. And I have seen it take as little as a week. But the average turnaround time, I'd say, is six weeks. So it's definitely something you want to get started right away.
Tim Bornholdt 3:33
And a lot of times people want to know what they can do to help in this process. And that's probably, as a business, if you're coming to it even as a startup, you know, you want it to be listed as your startup's name. You don't want it to be listed under your personal name. So get on top of that DUNS number right away.
Rob Bentley 3:48
And the other thing you want to take care of early too or at least get the process started is getting a privacy policy in place. You will not be allowed to have your app on the App Store without one, so it's very mission critical.
Tim Bornholdt 4:01
Yeah. And it's also just the right thing to do. Legally, you have to have a privacy policy. But it's also good to be a good steward of your users' data and tell them how you're going to be using it. The problem with the privacy policy specifically is, a lot of times, you don't know what data you're collecting until you've built the app. But there's still some boilerplate things you can get in and have the process started. So just make sure you have that in mind that, you know, you're going to need to have a privacy policy and you might have to need Terms of Service too, so having those legal documents drafted or at least having the conversation started right away with your attorneys is going to save you a lot of time down the road. Because we've been in a situation too, Rob, like a couple of times where we go to submit the app and everyone's excited and ready to go. And then it's like, Hey, where's the privacy policy? And then it's like, nothing kills a buzz faster than needing to call your lawyer. So make sure it's on your radar and get it taken care of right away.
Rob Bentley 4:56
Right. If you're lucky, your lawyer will do it right away, but sometimes lawyers just work on lawyer time. So that's definitely something to watch out for.
Tim Bornholdt 5:04
Absolutely.
Rob Bentley 5:05
Another thing that you want to be thinking about as you're creating your developer account is, for Apple and iOS apps, it is a yearly subscription. It does cost $100 a year to have a developer account for Apple.
Tim Bornholdt 5:17
That's true, you do need to make sure you've got that 100 bucks plus tax on an account that doesn't get cancelled. Because if you do the auto renewing thing, sometimes that doesn't work right. And then your apps get pulled from the store if you don't pay up your account. So make sure you're checking that and checking it every year to make sure that you are actually paying for it.
Rob Bentley 5:39
Right. So you've decided you want to have an iOS app, you've gotten all of your setup done. Now what are you going to need to be successful?
Tim Bornholdt 5:47
Yeah, I think one thing that a lot of people want to know when it comes to building iOS apps is, what kind of hardware are you going to need to get things done? Now, a lot of people listening to the show probably aren't going to be going out and building things themselves, like actually coding and opening up Xcode and doing that. But it helps sometimes if you have a Mac computer. At least you as the end user, you could learn enough to run simulator builds. And that just kind of makes the cycle go faster. So you might want to consider getting an Apple laptop, or you can even get like a cheap Mac Mini or something, just any thing from the last five or six years basically. One of our iOS developers had a laptop that was like 10 years old, and was still using it. It worked fine. It just took a while to build software. You know, any kind of hardware will work for you. But if you're interested in actually developing Mac software, don't try to do the thing people try to do where you use a PC and kind of hack Mac OS onto it or whatever. Just get a Mac or some piece of Mac hardware secondhand and do it that way.
Rob Bentley 6:57
Yep. And what a lot of people do too for testing out iOS apps, they'll just get iOS devices. So this will be your iPhone primarily. But also you could get an iPad or you could use an iPod, all of them work for testing. Phones work the best for testing all situations, especially if you have a data plan hooked up to it so that you can rely on cell signal for internet and location updates and things like that.
Tim Bornholdt 7:24
And there's different features inside the phone that will let you simulate if you're on like a bad connection. And so you can test different things. As long as you have the cell signal to start with then you can test and simulate different cases. But it is nice to have a couple of different devices, like a big screen and a small screen so that you can see what your app is going to look like for a bunch of different users. And that's one thing we've run into frequently is, you might design your app to look good on like an iPhone SE for example. But then when you look at it on an 11 Pro Max or you look at it on a giant screen, it looks really bad. So it's nice to have a bunch of different devices to test with.
One thing I wanted to touch on in this same thing is with hardware, a lot of times people, if they want to test new versions of iOS, like every summer, Apple will release a new version of iOS. Right now we're recording this in the summer of 2020, and iOS 14 is scheduled to come out in the fall. So we're busy testing our clients' apps on the new OSs. But the biggest rookie mistake you can do is, the day that the operating system comes out you install it on your main phone. Don't do that. We've learned so many times the hard way when we got excited and installed beta software on our phones, and it makes it so you can't even hold phone calls or your phone doesn't turn on sometimes. I mean, it's beta software for a reason. So we recommend if you're going to test the beta versions of iOS, go out and buy an iPod touch, something cheap that you can throw the new version of iOS on and then test your software on that.
Rob Bentley 9:02
Yeah, well, we're recording this in 2020, the iPod Touches are around $200. So they're not too expensive. And you can easily get a device to test most features out with. Again, the best device you can use as an iPhone, but the iPod Touches do mostly everything that a phone does. There's just a couple extras on the phone.
Tim Bornholdt 9:21
Right. And you don't even need to go buy a brand new one; you can go get a secondhand one off eBay or something like that, if you're trying to be cost conscious about it. But yeah, just finding some other device that you're not worried about losing data. That's really the important part here.
Rob Bentley 9:38
Yep. So now we're kind of at the stage where we've done all of our setup, we've tested out the app, we're ready to deploy. What a lot of people don't know is that before you can actually put your app into the App Store, apps have to go through a process called Apple Review, where you have to wait for a period of time. In the old days, it took anywhere from 7 to 14 days to wait for your app to be reviewed. They have gotten their process down to where it normally takes one day now, which is a lot better, but they'll be looking to make sure your app conforms to their guidelines. And those are posted on their website. So you will want to take a look at those primarily to make sure the main purpose of your app doesn't violate the guidelines. And then there are other things that developers are used to looking out for too to make sure that the app will fit into the guidelines, but there's quite a few of them. So it's good to be familiar with those.
Tim Bornholdt 10:32
And a lot of times if you're building an app brand new that's never been built before. it's hard to imagine that there's a lot of apps that don't exist, especially in 2020, where there's like, you know, a few million apps out there. But if you're trying to really do something innovative and brand new, and you've never built an app before, you might want to try to Google around or search in the App Store itself to try to see if you can find examples of apps that are already on the store that do kind of what you want to do. Because if you find that there's nothing out there for what you're trying to do, it might not be because people haven't tried. It might be because it's violating the rules and Apple won't like actually come right out and tell you if your app will be okay to build or not. Like you can't call them ahead of time and be like, Hey, I'm gonna spend a year building this app. Is that cool? Can it be on the store? Their answer is going to be, Well, send it through App Review, and then we'll tell you. So that's something that before you even start coding anything, take a look at the App Review guidelines. It's not that long of a read. And it's really interesting what kind of apps do get rejected and what Apple is really trying to keep off their platform. But either way, it's good for you to know from a business standpoint, what Apple will and will not allow on their store.
Rob Bentley 11:46
Yeah, kind of along with that, too, is part of what they'll look for in review is to make sure that your app conforms to their design guidelines. It's called Human Interface Guidelines or the HIG for short. This is another other good thing that you can take a look at and read beforehand, especially if you're not familiar with iOS apps and how they look and how they work and just the whole user experience around them. Apple does take a look at that too during review to make sure that, you know, it's easy to use and also conforms to their guidelines.
Tim Bornholdt 12:22
Yeah, the HIG is awesome. And really explains how a good app works on the App Store. It's things that you probably wouldn't have ever thought of like, you know, how many pixels high is your finger? Like when you tap on the screen, how big should a tap target be so that the average size finger can tap on it? Which it's 44 points, right, Rob?
Rob Bentley 12:46
Yeah, and we usually go a little bigger than that. We usually go 50 just to make a little bit easier. But it's a lot of things like that where you should try to follow these guidelines, not only to get through review, but to also just make your app really well done and a good user experience for everyone using it.
Tim Bornholdt 13:06
One tip that we've learned over the years too, is when you are starting from scratch, one of the first things that you have to determine is how many versions of iOS you'll support. So we'll get into this with Android where there's, you know, so many different things that you need to worry about. With iOS, what they typically suggest is that you support the latest current version that's out to the public, and then one previous to that. So like right now, in 2020, if you're building an app today, you know, we would advise that you'd aim for iOS 14, which is going to be out by the time you release your app, and then also support iOS 13. But if you're building an app completely from scratch, no one's ever downloaded it before, then what we would suggest is just target only the newest version of iOS because as your app grows and gets more mature, you know right now iOS 14 is awesome, but in five years, people are going to be, like Rob, are going to be annoyed that they're going to have to support something from a long time ago. So you can give yourself kind of a boost in that technical debt where you don't need to focus on supporting people that are running older devices. If you don't have to support anybody at this point, because you don't have an app, then just target the latest version of iOS.
Rob Bentley 14:22
Yeah, and you can go back versions if you really wanted to, but that will add to budget for development if we have to support legacy devices and legacy operating systems. So it's for sure most cost effective to go with the latest operating system and then go from there. And it's usually not a bad idea too as years go on to keep raising your minimum to what's current, maybe a year or two back but not still supporting operating systems from six to seven years ago, because that technical debt will just keep building.
Tim Bornholdt 14:55
And iOS users in general are good about updating to the latest versions of iOS, and Apple found a weird way that people are really driven by emojis. And they want to get like the latest newest emojis. And the only way you can get those is by updating your OS. So it's, you know, kind of one of those, whatever works situations. But it's great news for you as an app owner, because as Apple releases new OSs, they put new features in as well. And you have to, you know, have your app support the new features, and you want to also support the old features. So you kind of have to work with your developers to figure out what versions you're going to target. But again, as a general rule of thumb, it's whatever version is live right now, the latest version, and then one version back from that is typically what we suggest that you support as an app.
Rob Bentley 15:43
Yeah, and with the phone cycles, people getting new phones more frequently, a lot more users are just always going to be on the latest operating system. And I think it's something like between two weeks and a month after the newest Apple OS comes out, you'll usually see over 90% of iOS users on that version.
Tim Bornholdt 16:03
Yeah, it's usually in the first month, I'd say it's more like 50%. But then definitely within like two months or three months, then it's up into that 90% range, which, even like 50% is kind of unheard of in this industry for people to adopt new operating systems like that. And then to get to 90%, which if you look at some of our most popular apps, it's like 90% is pretty much where we're at now on iOS 13. It's pretty cool how quickly people, and it's great for developers, because then we don't have to worry about supporting iOS 7 or something, you know, ridiculous like that. We can just focus on the new stuff and make the apps feel faster and work better.
Rob Bentley 16:44
Exactly. So when the developers have written code, and they're ready to show it to you, this is also somewhat of a process too. So the means by which you will get an app onto your phone to test is an app called TestFlight. It was a standalone app and then Apple bought it and incorporated it into their system. What this means is it's an app, kind of like the App Store, that allows you to download the newest version that your developer has put out. Within your developer account, you can have two different types of users for distributing the TestFlight. The first is called internal. What this means is, as soon as a developer pushes a build to TestFlight, you'll be able to get it and then review it. And then there's external users, which has a separate review process. So you can send a few builds to internal, and then you can verify and say like, Okay, I think this is great. And then you can push it out to a different group of users who are your external users. And you can even have different groups within your external users. And then you can kind of control the process with quality based on testing the internal apps first and then sending one to external.
Tim Bornholdt 17:54
Like a good use case of this would be, the internal would be just your team, like the CEO and whoever else is directly working on this project, and then your external would be people that would only get... Because the internal builds usually have more bugs in them, I'd say. Tt's more of like a, you want to catch all the bugs internally before you bring in external people. So you don't want to have every build go to everybody. But TestFlight kind of makes this process a little more seamless for you to set up. You just designate whether a user is internal or external. And you're limited also, you know, with how many internal users you get, and you have to set up different things to get internal users. It's a little more of a process to do that. The external ones you can set up like a link, and direct people to that if you want to try to get beta users to test out new features or whatever in your app. But yeah, all of that is through TestFlight. That's a tool that you as a product owner are gonna really want to become more familiar with and incorporate. One cool thing with TestFlight too is you can directly send feedback to the developers by taking screen shots and leaving annotations of, I clicked on this and this and then something popped up here. All those kind of tools are made available when you distribute your app through TestFlight.
Rob Bentley 19:10
Yep. And you can also when the app crashes, if you're on a TestFlight build, you can also send that data back to the developer, which is great. And it's a newer feature. But you're also, for crash reporting and finding bugs, you're going to want to make sure your developers have set up a crash reporting software within the app too. The biggest one right now is Firebase who just acquired Crashlytics. There's another one called Instabug and probably a couple others, but we at JMG primarily use Firebase for our crash reporting.
Tim Bornholdt 19:43
Well, yeah, this is really a useful tool for developers because when you when you get these crash reports, if you just get the raw reports, it doesn't really help, doesn't really make a lot of sense, and feeding your data like this into a crash reporting service, they have all these tools and graphs and things that make it so we can track, you know how often a bug happens. If a bug is regressed, where you know, for example, in version, like 1.1 of an app, if we see a bug comes out, so then version 1.2, we fix the bug, but then version 1.3, we find that that same bug comes back, it'll be able to connect all of that together. So there's a lot of really advanced features. And for the most part, it's free, which, you know, they're obviously, like Google's mining data and stuff like that out of it, so they're getting they're getting paid somehow. But if you want to be more privacy centric, or you have qualms against that, for whatever reason, that's where there's services like Instabug and other reporting tools that you pay for. And maybe they're a little less robust or something like that, but they work just fine. And that's the whole point of it is for developers to be able to have tools to fix bugs as they come up.
I was gonna add one more thing with the with crash reporting. It's hard when we're developing apps, especially for apps that have millions of users using it, our QA process, our quality assurance process, can catch a lot of those bugs. But more often than not, there's bugs that we don't catch. And that we can't find unless they're at scale when lots of people are using the app in lots of weird ways. And that's what makes these tools so powerful is once it's out in the world, you need to be able to figure out how to reproduce those bugs. And that's the information we get from these tools really helps us to track those down.
Rob Bentley 21:36
There's a lot of useful tools that developers will use. Another one is called Fastlane. And this is an automation software. So it'll help make some tasks that happen with every app like gathering screenshots for the App Store, I guess, automated so that it helps save time.
Tim Bornholdt 21:54
Yeah, these tools are primarily, you know, we're giving you a lot of insider baseball about developer tools, but they're things that you as a product owner, even if you don't write code, you might interface with some of these sometimes, especially something like Fastlane, where if you have your app in multiple languages. And you know, with the way that Apple has the App Store Connect setup, you have to take screenshots for, you know, like iPad screen size and phone screen size. And they've gotten better about it over the years where you don't need to submit so many, but, man, if you have your language localized in 10 different apps, and you have to put five screenshots for three different devices, you know, that's like 150 screenshots, something like that, if my math's right, that you have to take every single time that you submit an app to the store. So something like Fastlane if you can get it set up with your developers, you can just run one command and then it does it all for you, in the course of a couple of minutes. You don't have to click anything, it just does it for you. So that's one reason I wanted to bring up Fastlane is you might hear about it and you might incorporate that into your workflow as your app starts to grow and scale.
Rob Bentley 23:02
Yep, another tool that developers will use, which is mostly a developer thing, but we'll touch on it quickly is Cocoapods. And what this is, is it's a dependency manager. And we use it for code that is very common across all apps, like handling networking requests that's been built, and it's, you know, been tested. And it's true. So we sometimes will opt to use a framework for doing certain things to save a lot of time with a code base that's proven to do a specific task.
Tim Bornholdt 23:36
Exactly. And Cocoapods is nice because things we've talked about already with like Fastlane and crash reporting tools, things like that, they all get incorporated through Cocoapods. So again, this is like if Fastlanes nerdy, this is even nerdier. You probably you probably won't get super deep into Cocoapods. But if you're building iOS apps, you might come across that phrase and it's a very weird phrase. So that's why I figured it's good to throw it in there.
Do remember what the other one is, Rob, that does dependency management for iOS? I know Cocoapods is the big one.
Rob Bentley 24:13
Carthage.
Tim Bornholdt 24:13
That's it. Yep. Carthage is the other one that does the same thing. It's just some developers prefer incorporating their dependencies in one way and some prefer it in another. So it's really just dependent on how your development team works. But those are two tools that you might hear those names thrown around. And that's just what they are, is it helps manage code for things that we don't necessarily need to rewrite every single time we build a new app.
Rob Bentley 24:39
Where you might hear about this mostly is if you see a crash report come in, and it's code from one of the dependencies. It might be a Cocoapod, and we don't usually have direct access to edit Cocoapods. We just have to report it to the developer who does the framework or maybe they have already addressed it because someone else is brought to their attention, and then we update the framework. But if we say, Oh, well, that's a Cocoapod, we don't have control over that code. That's more what that means.
Tim Bornholdt 25:08
Speaking of people reporting issues with apps, one thing that you're going to want to set up right away as well, and this is something that usually your development team helps you incorporate. But you're going to want to have some sort of feature request manager and development task manager. We at JMG use Trello. A lot of it depends on what you use internally with your own company. Some people really like the Microsoft stack, so they use DevOps. Some people really like the Atlassian stack, so they use JIRA. Trello, I think is also owned by Atlassian now. But it's a little different than JIRA. So just make sure that you at the outset, usually at the beginning, there's so much that needs to get done that it doesn't make sense to make individual tasks for all the different things developers have to do but especially once you have your version one out the door, you're going to get feature requests and issues and enhancements and things like that that come in. And you need to have some way to organize that. So look into those tools. They'll really help out with making sense of all the chaos.
Rob Bentley 26:15
Yeah, exactly. It's very helpful for defining just like, Hey, here's an idea for the future. Or here's a bug that needs to be handled right now. Or here's a new feature request. Here's what's in progress. Here's what we're testing right now. It really helps you keep a handle on just where everything is at, and not forget little things that need to happen.
Tim Bornholdt 26:32
One thing that we want to touch on is there's two ways to really distribute apps on iOS. Apple has the platform pretty well locked down, where on Android, you can just like email somebody an APK file, basically, and they can open it and do whatever they want with it. On iOS, there's really only two approved ways of getting apps onto a phone. And that's either with an enterprise account or an app store account. So maybe, Rob, do you want to go through the differences between the two?
Rob Bentley 27:01
Yeah, so the App Store account will be just your standard, what everyone is used to. You deploy the app, it's now in the App Store, people can download it and usually automatically updates, unless the user has specified they don't want that to happen on their phone. Enterprise is a little different. So this will usually be used for your own internal business, and you'll host it on one of your own servers. What this process will look like is your users that you want to have this app will go to a web link, and they'll click the link and it'll ask them, Do you want to download this app? Then they have to go into their settings and trust the provider. And then once they've done that, they can download the app. The thing about this is, when you deploy updates, usually they have to be manually updated as well.
Tim Bornholdt 27:51
Yeah, and there's software out there, like MDM, they call it, mobile device management, that will handle auto updates and things like that. But again, that's made primarily for internal business tools. If you're trying to reach a mass market, then you're going to be using the App Store. That's really the only way that most people will go. But if you are working in a large organization, and you're trying to do like a sales tool or something that you don't necessarily wouldn't want to have the general public downloading and accessing, then the enterprise account is where it's at. And you'll just need to go through some additional steps in order to get that account. Like we were saying how developer accounts are $100 a year, well, enterprise accounts are $300 a year. So it's just kind of differences like that, and your development team should be able to help you deploy correctly to whichever one you're going to go for.
Rob Bentley 28:43
And also let you know which one you need to use for whatever your use case is.
Tim Bornholdt 28:47
Yeah, we sometimes get clients that want to sneak like an internal business tool, for example, onto the App Store. And for the most part, we can find ways to pass that rule, but there's sometimes where it's like, Okay, this is an app to order lunch for your office. Like, that's clearly not something that you can pass off as an app that anyone's gonna want to download and use. So, you know, there's certainly exceptions that we can try to make. But in that case, it's like, no you've got to get into an enterprise distribution with that one.
Rob Bentley 29:21
Yeah, Apple will probably catch that and call you out on it and not let the app go through if they think it should be enterprise, and you're trying to get it in the public App Store.
Tim Bornholdt 29:30
Why you talked about the last one, Rob, with the wonderful new two factor authentication that we have to do?
Rob Bentley 29:35
Yep. So a couple of years ago, to make things more secure, Apple started requiring two factor authentication to access your developer portals for App Store Connect. And what this means is anytime your developer needs to go in and handle something on App Store Connect, it's going to ask you to two factor authenticate them, which can cause delays in deployment or writing code if you're not around to give them the code right when they need it. So something helpful you can do with this process is if you trust your development team or the project manager, you can make them a user on that account that has access to the two factor authentication so they can authenticate it themselves. And that helps speed things up a lot if you're able to get that set up right away.
Tim Bornholdt 30:22
It makes sense that they force you to do the two factor authentication because you can really like hose somebody over if they get access to your account. But it's something that you're going to want to set up right away is getting your development team trusted on that so that when we're developing at 11 o'clock at night on a Friday or something, you don't want to have to be like, Hey, can you wake up and give me the code so it can trust me as an authorized user?
Rob Bentley 30:46
Right. Go knocking on your door.
Tim Bornholdt 30:49
Kick it in and steal the phone.
So final thoughts. I mean, a lot of these tips, I'm assuming are things that are going to go in one ear and out the other because it's all like basically summarized a lot of mistakes and lessons we've learned over the last eight years. So this to me is going to be kind of an evergreen episode that you can keep coming back to as you're developing apps and, you know, get some more tips. But any parting words you have, Rob, about any special things that you've learned about building for iOS over the years?
Rob Bentley 31:19
I mean, there's more than I could probably cover in just a final thought, but I guess the biggest thing is just communicate with your development team. Because any of these hurdles that you're going to go through, they'll probably have gone through and should be able to help you out with whatever comes up or happens. That's what we're here for.
Tim Bornholdt 31:37
You're probably going to run into, if you have a novice team that has never built an iOS app before, they're going to run through a lot of these roadblocks. So send them this episode so they can get over the next one. Or better yet, switch teams over to the JMG and we can move you over those hurdles with relative ease.
Rob Bentley 31:57
Yeah, you can learn from our mistakes.
Tim Bornholdt 32:01
Exactly. We can only get over those hurdles because we've tripped over them so many times ourselves.
Rob Bentley 32:05
Exactly.
Tim Bornholdt 32:06
Well that's it for today's show. Show notes for this episode can be found at constantvariables.co. You can get in touch with us by emailing hello@constantvariables. co. I'm @TimBornholdt on Twitter. Are you Scott Mahonis on Twitter, Rob?
Rob Bentley 32:20
Yeah.
Tim Bornholdt 32:21
Do you ever go on Twitter?
Rob Bentley 32:21
No.
Tim Bornholdt 32:22
Okay, so yeah, don't worry about Twitter. Then the show is @CV_podcast. Today's episode was produced by Jenny Karkowski and edited by Jordan Daoust.
If you have one minute quick before you leave, we'd love it if you left us a review on the Apple Podcasts app. It shouldn't take that much time. It really doesn't. And it really does help new people find our show. So we've made it super easy for you. Just head to constantvariables.co/review, and we will link you right there.
This episode was brought to you by The Jed Mahonis Group. If you're looking for a technical team who can help you make sense of mobile software development, give us a shout at JMG.mn.