iOS junior watch dev question list

[patent10021]

I'm a junior dev and have an opportunity to develop a watch app version for an existing WeChat/Snapchat type of language learning/social iPhone app and being fairly fresh to development I have a few questions. My goal is to create a solid and very simple Version One watch app. The watch app will have basic glances such as:

Display most recent friend requests
Displaying recent favourited chat messages
Displaying recent favourited translation
User can send an emoji reply or speak a reply or defined canned responses
Display the 12 most recent chats represented by a small circle avatar of that buddy. User then clicks a buddy to send an emoji, canned response or audio message.

Questions

1. If you only want glances and you don’t want to create a full version watch app what do you do? Just let the iPhone Watch app handle the glances and notifications and simply create only a watch extension? Can an iPhone app send data to a watch to display a glance without creating a watch app? Glances still have to be set up via the iPhone Watch app right? Or with watchOS2 can glances be set up via watch directly (provided you created a watch app)?

2. How would I go about creating a login procedure for mock purposes if I temporarily don’t have access to the real server info? Would I use FireBase or Parse with a few fake user objects and then swap out the Parse code for the real server code later?

3. With watchOS2 the user doesn’t need the iPhone. The user will already have the iPhone version of the app. So should the user be logging in to their account via the watch or via the iPhone?

4. The iPhone app is written in Objective-C. This watch app will be written in Swift. Since it’s a watch app based on the iPhone app it’s obviously more simplified. If my glances and complications only involve user favourites, avatars etc and not full functioning app like the iPhone version how should I approach this?

5. Working remotely would the company expect me to mock it up via a 3rd party back-end first?

6. If they do give me their access to their user base and server data how do I manage this securely? I am working remotely so I’m not yet sure ho they will expect me to handle this. Of course we will discuss this but I’d like to hear from senior devs about this.

7. The company has all of the info I need of course. So should I recommend remote version control collaboration or should I ask them for what I need and work on my own?

8. This is just an initial presentation for the green light. What do you recommend for the least amount of stress? Don’t worry about all of the above and just present a Sketch Board?

9. As a junior dev what time frame should I give them? What is the usual time required for a basic watch app with basic glance features?

11. Should I be creating a new native app or a new target of the existing app? Which would be easier since the original iPhone app is a major app? It's written in Obj-C so that play a factor in my approach.

 

[Mascots]

I'm just catching up to some of your posts here, so let me see if I can answer these in a short and concise manner.

1. Each app only gets a single glance which is meant to show the most relevant and slimmed down information. A glance can contain multiple "scenes", though. Think of them as a single "window" into your application. Glances do not require a watch app (since are connected through the extension), but provide the best experience along side one. See Glance Essentials. Glances are managed only on the iPhone and communication is handled through WatchConnectivity.

2. This should be managed by your host app and synchronized with your Watch App extension. Ideally, you are only handling the synchronization of user sessions since you have no hand in the host app and the server interaction should be abstracted away from you. Remember, Watch Apps are companion apps, not independent apps.

3. See point above. You cannot have a Watch App without an iOS app, so sessions should be seamless to the enduser.

4. Your Watch App can be written in Swift while your host app can be written in Objectice-C, but you will need to bridge all of the appropriate things just as you would if the host was written in Swift importing obj-c components.

5. Mock it up, as in UI mock up? Sorry, not too clear on this one

6. Speak to them and how they handle this information. Ideally, you should understand structure without any need to know contents. However, they most likely have guidelines in place to handle working with secure data and other safe nuances. If they're asking you, I'd be quite concerned.

7. Git. 100% source control. You may as well break off a finger without proper control and management of source.

8-11. Speak to goals, what you want to achieve, how that relates to the people you are working for. Goals and relatable outcomes are the best way to resonate with people and this field particularly lacks it which can make technology and investment into technology very scary. You should also do your best to determine as many metrics as possible along with anticipating future platform growth (iOS 10+).

Timing is something that you'll have to gather on your own. It sounds as if you're just beginning to learn Watch App development, so the learning curve is going to set you back in multiple ways. First, there's the actual learning of everything, and then you'll need to refactor the initial code you conceptualized after you've reached that plateau in learning.

In your case, I see several setbacks already (from other threads and here). First and foremost is the lack of version control access and lack of access to the host app. If you have to mock together a host app, it will destroy you. If you have to copy and paste files and hope things line up, it will slowly chip away at you. You just cannot build a Watch app without a host, and it will be near impossible to build a good one that's based on mocked components. If you begin with glances, the moment you start working with WatchConnectivity you'll understand. The second, as I stated, is your level of skill and familiarity coming into Watch App development. You must read the Watch App programming guide before you plan or do anything, that's a given. There is a lot to take in and for all intensive purposes, it isn't iOS.

Overall, there's a lot of things for your situation that you need to take into consideration. One thing I suggest, well scream, to you is to not bite off more than you can chew and it sounds like you're very close to that.

 

[patent10021]

Each app only gets a single glance which is meant to show the most relevant and slimmed down information. A glance can contain multiple "scenes", though. Think of them as a single "window" into your application. Glances do not require a watch app (since are connected through the extension), but provide the best experience along side one. See Glance Essentials. Glances are managed only on the iPhone and communication is handled through WatchConnectivity.

Right. I'm reading docs and watching dev videos like a mad man UI is in the watch app and logic is in the watch extensions. A UI (watch app) isn't needed for a glance because the data is passed to the watch OS via extension logic right? You mentioned a glance can contain multiple scenes. In this case you still don't need to deal with the Glance Interface Controller because 3 glances can be coded then the switch for those 3 glances is in the iPhone watch app right?

2. This should be managed by your host app and synchronized with your Watch App extension. Ideally, you are only handling the synchronization of user sessions since you have no hand in the host app and the server interaction should be abstracted away from you. Remember, Watch Apps are companion apps, not independent apps.

But I thought with WatchOS2 we technically don't need an iPhone. Doesn't that mean it COULD be an independent app? Let's say a dev didn't care about a heart rate app for iPhone and just created a watch project. Dev could release just the watch app right?

4. Your Watch App can be written in Swift while your host app can be written in Objectice-C, but you will need to bridge all of the appropriate things just as you would if the host was written in Swift importing obj-c components.

But like an iOS project you'd only need a single header file right?

One thing I suggest, well scream, to you is to not bite off more than you can chew and it sounds like you're very close to that.

Exactly what I told my gf At first I was stressing but I realized there's no point. Fortunately I'm the one making the decision on the project time-frame. The project guarantees me a position on their team so it's sort of like a CV qualifier.

All is good now. I have access to their Git as well as group chat in the same host app we are talking about here. Their user base is in the several millions globally so they are quite serious about giving me everything I need lol

I really appreciate you taking the time to write a lengthy reply to help me out.

 

[Mascots]

Right. I'm reading docs and watching dev videos like a mad man UI is in the watch app and logic is in the watch extensions. A UI (watch app) isn't needed for a glance because the data is passed to the watch OS via extension logic right? You mentioned a glance can contain multiple scenes. In this case you still don't need to deal with the Glance Interface Controller because 3 glances can be coded then the switch for those 3 glances is in the iPhone watch app right?

Sort of, you don't need an app because the extension facilitates the communication but you need a WKInterfaceController subclass & storyboard glance entry to manage the setup of a UI. I'm sure that you've come across Managing Your Glance Interface, but if you haven't give it a quick read.
What you should be doing is setting up your different "scenes" as groups in your Storyboard and showing and hiding them based on whatever is most relevant. For example, rather than having an option to choose what you see there, the Glance controller instead determines that you have a pending unread message and communicates that to the end user by displaying the "new message" group and making all of the others invisible. If you were to not have a message, then the glance can hide the "new message" group and then show the "basic overview" group in that storyboard view.
Glances cannot be interactive and are meant to provide a user with the most relevant information without the user having to do anything other than bringing up your glance. Requiring your user to mess with an option to change that particular view, especially nested in an app, can quickly defeat that purpose so be careful with how you approach it.

But I thought with WatchOS2 we technically don't need an iPhone. Doesn't that mean it COULD be an independent app? Let's say a dev didn't care about a heart rate app for iPhone and just created a watch project. Dev could release just the watch app right?

No. At its core, the Apple Watch is not meant to be anything more than a companion to iPhone and that methodology extends into the way the inner components are built. Interactions are meant to be <10 seconds and use Handoff to encourage deeper and complicated interactions in their big-brother counterparts.

So basically: While Watch Apps can run independently of their iOS host apps, they require a host app to be distributed and offer oversight of the extension. In your example, a heart-rate monitor watch app would have to be packaged inside of an iOS host app - the Watch App focusing on gathering results & delivering quick information to a user (such as todays stats) while the full iOS counterpart would supply things like settings, extended history reports, editing, sharing information to social media, etc. There is just no way not to do this.

In an example that is relevant to you, let's assume the user can only download the Watch App. When they are prompted to log in for the first time (since a session could possibly not exist on the iPhone lacking your host app), how do they enter their details? There is no keyboard for Watch OS, at least not one that can handle usernames and passwords (this is a big reason there isn't a UI for wifi!) so how does your user enter those details? Do they need to go to another device and sign into a mobile app that presents them a number that syncs them to a service? That's complicated and requires another device anyway. If it was tied along side the iOS app, it means that instead your Watch App can hand you off to its host for gathering those details.

The running of the extension on the Watch has benefits that majorly impact developers and allow them to achieve a level of quality comparable to Apple's stock apps. For example, when responding to a tap in the UI, the Watch app extension can immediately determine the response; in Watch OS 1, that tap would have to make a trip to the iPhone to get the proper response and then round back with the details for the reaction. That time is eliminated with native apps. The ability for an app to run independently of an iPhone is more-or-less a (of course wanted) side-effect of this.

There are also a few other things: With NSURLSession, you are able to fetch information from the web without having to round trip to the host app which contains this information. This, of course, presents a lot of options to the developer and how they want to manage their data to make it perceivably instant to the end user because things like Watch Connectivity allow you to queue information for processing. I really suggest watching this chat about WC and interactions with your parent app - it will help show you the value of building the two together.

~~

As for your other things, yeah, you'll only need a single header. And as far as having the GIT, thank jebus because you would have had no way of doing this project otherwise.