Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

patent10021

macrumors 68040
Original poster
Apr 23, 2004
3,537
813
If you had a native Swift iPhone app and simply copied the files over to the watch project, what would be the basic check list of things you'd need to change?

ViewController names
Plist keys
Project settings - make sure team and frameworks etc are set right
make sure dependencies i.e. Pods are installed correctly


What else? Is it pretty much just a case of drag and drop and confirming things match up?
 
If you had a native Swift iPhone app and simply copied the files over to the watch project, what would be the basic check list of things you'd need to change?

ViewController names
Plist keys
Project settings - make sure team and frameworks etc are set right
make sure dependencies i.e. Pods are installed correctly


What else? Is it pretty much just a case of drag and drop and confirming things match up?
The Watch app isn't going to be a separate xcode project. The watch app will just be an additional target in the ios xcode project.

Do some reading on how watch apps work. You're not gonna be copying over view controllers and such. You might use a few of the same frameworks, classes, and image assets, but that's about it. I wouldn't suggest copying it either, you can just make it so that the same file is available to both targets
 
Usually yes. But possibly not in this case. Unless I have access to the same version control system it will be a separate project built purely in Swift since I am remote. You'd think I will have access but for various reasons I might not have access to the same version control system for a few months.

Anyway I've broken it all down and it doesn't seem that difficult. I'm just creating separate VC/Swift files for each scene as usual i.e.

MainChatVC (main scene with list of chat sessions)
ChatMessageVC
RecordVoiceVC (Voice Recorder with HUD)
SendLocationVC
PickImageVC etc.

What I'm wondering about is all the server side stuff. They aren't using Parse/FireBase etc so I'm not sure how to connect since I've only ever used Parse/Firebase. I guess it's all the same really.

Btw, since you mentioned it. If their iPhone app is Obj-C and I end up creating a watch target in their app, I can go ahead and just create everything in Swift? Do I need a bridging header file for the watch app?

And when you see an app in the app store and below it it says watch version available is that because the watch target is in the same project? Or can you have a separate project/app store submission and it will still say "watch version available"?

Hey, are you a senior dev? Do you have experience with chat apps?
 
Why can't they create a branch for you to work exclusively in? Or why can't they allow you to check out your own copy to create a branch for local editing? Assuming you're using GIT, you'll be free simply merge their changes into your branch and eventually merge your branch into the master. Not giving you access to an existing repo is setting you up for a failure that isn't your fault, but will blow back on your shoulders, IMO.

I say this because, as AN said, it's going to become more-and-more of a chore to attempt to build a Watch App independently of its host application. Think about attempting to build a Today widget without having the app behind it - while Watch OS 2 makes this a little less relevant, it's the same principal (just like Today widgets, Watch Apps are extensions to apps). I suggest checking out the Watch apps architecture.

By your plan, it sounds as if you'd essentially need to mock your host app, which may or may not work or take large amounts of time and effort, only to dump that work for the host app that already exists, while hoping the integration is clean enough or implementation hasn't changed. Not to mention, regardless of how hard to attempt at keeping things synchronized, making merges of a unique Xcode Project into an already built & defined Xcode Project will be so incredibly painful.

I can't advise you off this course more. At the very least, you need a checked-out complete copy of their repo. None of this copy files and mocking app BS.
 
Why can't they create a branch for you to work exclusively in? Or why can't they allow you to check out your own copy to create a branch for local editing? Assuming you're using GIT, you'll be free simply merge their changes into your branch and eventually merge your branch into the master. Not giving you access to an existing repo is setting you up for a failure that isn't your fault, but will blow back on your shoulders, IMO.

I say this because, as AN said, it's going to become more-and-more of a chore to attempt to build a Watch App independently of its host application. Think about attempting to build a Today widget without having the app behind it - while Watch OS 2 makes this a little less relevant, it's the same principal (just like Today widgets, Watch Apps are extensions to apps). I suggest checking out the Watch apps architecture.

By your plan, it sounds as if you'd essentially need to mock your host app, which may or may not work or take large amounts of time and effort, only to dump that work for the host app that already exists, while hoping the integration is clean enough or implementation hasn't changed. Not to mention, regardless of how hard to attempt at keeping things synchronized, making merges of a unique Xcode Project into an already built & defined Xcode Project will be so incredibly painful.

I can't advise you off this course more. At the very least, you need a checked-out complete copy of their repo. None of this copy files and mocking app BS.
Yeah...I don't know if he's dealing with clueless executives or sone thing but whoever is telling him to develop the watch app without the actual iOS application is kind of ignorant.


What I'm wondering about is all the server side stuff. They aren't using Parse/FireBase etc so I'm not sure how to connect since I've only ever used Parse/Firebase. I guess it's all the same really.

Btw, since you mentioned it. If their iPhone app is Obj-C and I end up creating a watch target in their app, I can go ahead and just create everything in Swift? Do I need a bridging header file for the watch app?
It sounds like you're getting in way over your head here. I would suggest that you try to politely back out of this if possible. It seems that not only do they not know much about ios development, you don't either. Not trying to be rude. You're getting yourself into a bad situation.

Parse and Firebase are very different from most backends that ios apps use. For example I generally make my own backends in Node.js and use HTTPS requests in iOS to communicate with the server. Experience with Parse isn't gonna be much help with making HTTP requests but it depends on if they're returning JSON or some weird data format.
 
Last edited:
Yeah...I don't know if he's dealing with clueless executives or sone thing but whoever is telling him to develop the watch app without the actual iOS application is kind of ignorant.



It sounds like you're getting in way over your head here. I would suggest that you try to politely back out of this if possible. It seems that not only do they not know much about ios development, you don't either. Not trying to be rude. You're getting yourself into a bad situation.

Parse and Firebase are very different from most backends that ios apps use. For example I generally make my own backends in Node.js and use HTTPS requests in iOS to communicate with the server. Experience with Parse isn't gonna be much help with making HTTP requests but it depends on if they're returning JSON or some weird data format.
I thought Parse/Firebase could handle requests even for the number of requests carried out by smaller companies. So I just need to find out what they wrote their back-end in. Good news is I have full access to their Git and group chat so all is good. I was pretty much just thinking worst scenario. Thank you for your advice AN.
 
Last edited:
I thought Parse/Firebase could handle requests even for the number of requests carried out by smaller companies. So I just need to find out what they wrote their back-end in. Good news is I have full access to their Git and group chat so all is good. I was pretty much just thinking worst scenario. Thank you for your advice AN.
I'm not sure what you mean. Parse/Firebase is very different than interacting with a Node.js server. With Parse you build database queries on the actual iOS application (PFQuery), unless you're using cloud code or something. Parse takes care of most of the details and they make it easy. But with a Node.js server you have to do EVERYTHING yourself. You have to build the actual HTTP requests (like POST, GET, etc). You receive a JSON data response and serialize it to become a usable object. If you've only ever worked with parse/firebase, then you are in for quite a big change. You have to handle slow responses, failed HTTP requests, partial or incorrect data, error handling, etc. Your Parse experience is not gonna help you very much.

I really have to reiterate that you should probably turn down their offer/contract. One day you will have enough experience but right now I think the gulf between what you know and what you need to know is so large that you won't be able to keep up. The biggest problem with new inexperienced developers is that they are often too confident, and don't realize how little they actually know. There's actually a term for this because it is common in many fields, it's called the Dunning-Kruger effect.
 
Last edited:
I'm not sure what you mean. Parse/Firebase is very different than interacting with a Node.js server. With Parse you build database queries on the actual iOS application (PFQuery), unless you're using cloud code or something. Parse takes care of most of the details and they make it easy. But with a Node.js server you have to do EVERYTHING yourself. You have to build the actual HTTP requests (like POST, GET, etc). You receive a JSON data response and serialize it to become a usable object. If you've only ever worked with parse/firebase, then you are in for quite a big change. You have to handle slow responses, failed HTTP requests, partial or incorrect data, error handling, etc. Your Parse experience is not gonna help you very much.

I really have to reiterate that you should probably turn down their offer/contract. One day you will have enough experience but right now I think the gulf between what you know and what you need to know is so large that you won't be able to keep up. The biggest problem with new inexperienced developers is that they are often too confident, and don't realize how little they actually know. There's actually a term for this because it is common in many fields, it's called the Dunning-Kruger effect.
I believe you. Question. since I have access to the host app all the HTTP request code is already there. Surely I can reuse it and convert it from Obj-C to Swift. Why wouldn't I be able to do that? Even if I couldn't there are a billion tutorials on Swift + parsing JSON data and making REST API calls etc.

They're letting me dictate the project deadline so if this is the hardest part of the app I could get up to speed with more advanced API calls and parsing in no time. As programmers we already know how to read code. I just need to adapt to the syntax like anything else.

You disagree?
 
Last edited:
I believe you. Question. since I have access to the host app all the HTTP request code is already there. Surely I can reuse it and convert it from Obj-C to Swift. Why wouldn't I be able to do that? Even if I couldn't there are a billion tutorials on Swift + parsing JSON data and making REST API calls etc.

They're letting me dictate the project deadline so if this is the hardest part of the app I could get up to speed with more advanced API calls and parsing in no time. As programmers we already know how to read code. I just need to adapt to the syntax like anything else.

You disagree?
The biggest problem isn't the code at all. The syntax, methods, classes are pretty easy to learn. Doing something, and doing something well, are two very different things. I'm sure you can do it, but since this is your first commercial project and you will be the only person working on the watch app, it will probably be a slow buggy mess. That's just the reality of the situation.

I just fundamentally disagree with the idea of entering a contract or a job without having at least some basic experience with most of the critical parts of the project, ie. Knowing the basics of how a watch app actually works. It's just not enough to read a few tutorials online.
 
Last edited:
The biggest problem isn't the code at all. The syntax, methods, classes are pretty easy to learn. Doing something, and doing something well, are two very different things. I'm sure you can do it, but since this is your first commercial project and you will be the only person working on the watch app, it will probably be a slow buggy mess. That's just the reality of the situation.

I just fundamentally disagree with the idea of entering a contract or a job without having at least some basic experience with most of the critical parts of the project, ie. Knowing the basics of how a watch app actually works. It's just not enough to read a few tutorials online.
I also agree. Which is why I'm happy that they are letting me dictate the time-line lol Don't ask me how I got this opportunity. It's ridiculous I know. But as you know, I cannot resist the force of the Dunning-Kruger effect. Anyway sometimes illusions become reality so I'll give it a shot. We only have so much time on earth. I don't want to think what if I had tried this. I have sourced a mentor and project time is on my side. I can see the light at the end of the tunnel. As Napoleon Hill or Dale Carnegie said, "What's the worst that can happen?". I am unable to complete it and I move on and study more. I think I can live with that.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.