iOS A Couple of Questions About iOS Programming

[mildocjr]

I'm in the process of writing my first App that I will publish to the App Store (Xcode 8, iOS 10).

I plan on doing most of the code writing without a developer account then buying one when I reach a point where it's required (CloudKit).

As I am going out of pocket for this app, I plan to implement social networking features in a later version and I would like to consider the best options that would prevent less maintenance later on. I do not have any experience with using third party libraries and wish to keep my dependencies on third parties minimal.

Storing Data

My app will feature displaying user-specific data from JSON input. The size of the JSON data is roughly 1.3 MB and contains a list of locations where I will provide the closest location to the users. My initial thought was to download the data every time, but in the spirit of moderating cellular data usage, I decided to store it. Some places say that it's fine to store this data in NSUserDefaults, whereas others say use Core Data for large amounts of data. Since my JSON data is approximately 30400 lines and each object is 13 fields two of which are the coordinates of the location, I'd think the best way is to use Core Data.

As new places will not be created often, I plan to download the JSON data on a monthly basis just to ensure the most up to date information is available.

There will also be user-specific details some of which will update and should link to a specific time frame. It sounds like a job for a relational database but the amount of data stored will be minimal.

In later versions, I plan to take this data and share it securely with a family member or family members, which is where I have the hang up with using Core Data initially.


What would be the suggested way to store this data?


Proper order for UI, Code, or Data

I am not a designer and I'm spinning my gears trying to write the UI in a way that it works Landscape on iPad, Portrait on iPhone, and supports the iPhone 4s with the layout.

I would like to get my data in working order along with the minimal code for a very alpha UI so I can test out the download, storage, and data retrieval up and running. Since the app will function differently based on the users current status, I would like to implement data retrieval at a later point in the app. There are 4 possible user states, initial setup, Before, During, and After. I will figure out how to change the initial view controller later, but for now I am only interested in retrieving the data in the Before and After states.

Is it acceptable to create a basic mock-up in the Interface Builder that provides enough functionality to navigate through the app to ensure some of the features are working before I focus in on the UI?


I know these are pretty basic questions but I want to prevent myself as many headaches as possible when I start working on later versions of the app. I know I wrote a book but I wanted a clear explanation of what I'm trying to do. Feel free to ask me questions if you need clarification.

 

[grandM]

I'm in the process of writing my first App that I will publish to the App Store (Xcode 8, iOS 10).

I plan on doing most of the code writing without a developer account then buying one when I reach a point where it's required (CloudKit).

As I am going out of pocket for this app, I plan to implement social networking features in a later version and I would like to consider the best options that would prevent less maintenance later on. I do not have any experience with using third party libraries and wish to keep my dependencies on third parties minimal.

Storing Data

My app will feature displaying user-specific data from JSON input. The size of the JSON data is roughly 1.3 MB and contains a list of locations where I will provide the closest location to the users. My initial thought was to download the data every time, but in the spirit of moderating cellular data usage, I decided to store it. Some places say that it's fine to store this data in NSUserDefaults, whereas others say use Core Data for large amounts of data. Since my JSON data is approximately 30400 lines and each object is 13 fields two of which are the coordinates of the location, I'd think the best way is to use Core Data.

As new places will not be created often, I plan to download the JSON data on a monthly basis just to ensure the most up to date information is available.

There will also be user-specific details some of which will update and should link to a specific time frame. It sounds like a job for a relational database but the amount of data stored will be minimal.

In later versions, I plan to take this data and share it securely with a family member or family members, which is where I have the hang up with using Core Data initially.


What would be the suggested way to store this data?


Proper order for UI, Code, or Data

I am not a designer and I'm spinning my gears trying to write the UI in a way that it works Landscape on iPad, Portrait on iPhone, and supports the iPhone 4s with the layout.

I would like to get my data in working order along with the minimal code for a very alpha UI so I can test out the download, storage, and data retrieval up and running. Since the app will function differently based on the users current status, I would like to implement data retrieval at a later point in the app. There are 4 possible user states, initial setup, Before, During, and After. I will figure out how to change the initial view controller later, but for now I am only interested in retrieving the data in the Before and After states.

Is it acceptable to create a basic mock-up in the Interface Builder that provides enough functionality to navigate through the app to ensure some of the features are working before I focus in on the UI?


I know these are pretty basic questions but I want to prevent myself as many headaches as possible when I start working on later versions of the app. I know I wrote a book but I wanted a clear explanation of what I'm trying to do. Feel free to ask me questions if you need clarification.

I cannot answer all of your question but I'm sure there are many people whom will help you out here. Some things I can answer though. In Interface Builder you can use constraints. These constraints will set your view for some devices. However using size classes you can create multiple views for your app. So you do not nee to go instantiating stuff in code or so.

UserDefaults should not be used for this much information. You can go CoreData or CloudKit. They are two different frameworks though with their own functionality.

 

[mildocjr]

In Interface Builder you can use constraints. These constraints will set your view for some devices.

Yeah, I've been working with the constraints but they've been very finicky when switching between different layouts. Even though I have a title label, a standard 2 line label, two buttons and another label, elements keep getting pushed off or they are not transitioning properly between layout views. I also plan to adjust the layout to be more iPad Friendly as this leaves a lot of wasted space on the iPads in landscape. (eg. Facebook login on iPad Pro.). I may have to get more acquainted with adjusting for size classes.

You can go CoreData or CloudKit. They are two different frameworks though with their own functionality.

Is it difficult to shift between Core Data and CloudKit?

 

[grandM]

Yeah, I've been working with the constraints but they've been very finicky when switching between different layouts. Even though I have a title label, a standard 2 line label, two buttons and another label, elements keep getting pushed off or they are not transitioning properly between layout views. I also plan to adjust the layout to be more iPad Friendly as this leaves a lot of wasted space on the iPads in landscape. (eg. Facebook login on iPad Pro.). I may have to get more acquainted with adjusting for size classes.

Yes you ought to look at size classes first. Else the view for an iPhone will be the same as the one for an iPad and you probably do not want that. As for constraints you can also set constraints like hugging, compressing and <= for instance. That should solve some of your problems.

Is it difficult to shift between Core Data and CloudKit?

I think the first question you ought to ask yourself is if you also want to support android devices. If so CloudKit makes no sense. I have fooled a lot around with CoreData but CloudKit is still on my bucket list. It didn't seem so hard. If I would have to do it over I'd go for CloudKit immediately. The money you save you will pay greatly in time spent. That is my impression anyways. Maybe some other macrumors members did the transition or succeeded in combining them. This forum is truly a great choice. People are friendly over here and try to help you out whenever they can. Welcome

 

[mildocjr]

As for constraints you can also set constraints like hugging, compressing and <= for instance.

Yeah I've been working with greater than, but it still throws my Title label way off to the left. Dabbling with Autoresizing seems to help a little but I was going to leave that for last if at all possible.

I plan to make this app for Android as well, but at a later time when I have the resources and a clear goal because I'm not clear with Android UI/UX design. As I know a little about Java since I learned C# (similar languages) I know close to nothing about Android development but it is an end goal and by that point I hope to have made enough from the ads and donations through the app that I will be able to afford my own hosted server with a common data layer front-end that can handle data from two different platforms and provide connectivity between iOS and Android users. The reason I considered CloudKit is for a free hosted back-end until I have the funding to afford a better AWS or Azure-based back-end.

I'm sure people will cringe at this, but I have to get creative and resourceful because I don't have a lot to invest in up front.

I do appreciate the advice and insight, it's very valuable.

 

[grandM]

Yeah I've been working with greater than, but it still throws my Title label way off to the left. Dabbling with Autoresizing seems to help a little but I was going to leave that for last if at all possible.

I plan to make this app for Android as well, but at a later time when I have the resources and a clear goal because I'm not clear with Android UI/UX design. As I know a little about Java since I learned C# (similar languages) I know close to nothing about Android development but it is an end goal and by that point I hope to have made enough from the ads and donations through the app that I will be able to afford my own hosted server with a common data layer front-end that can handle data from two different platforms and provide connectivity between iOS and Android users. The reason I considered CloudKit is for a free hosted back-end until I have the funding to afford a better AWS or Azure-based back-end.

I'm sure people will cringe at this, but I have to get creative and resourceful because I don't have a lot to invest in up front.

I do appreciate the advice and insight, it's very valuable.

how about firebase then, it's also free to start with

 

[mildocjr]

how about firebase then, it's also free to start with

How often is it updated and does it create a lot of App maintenance? I'm not trying to completely shun third parties but I would also like to involve myself with multiple apps. As a solo developer/designer/everything else It would be pretty difficult to have multiple apps out there and have to worry about keeping up with the dependencies along with refactoring my code to work with Swift vNext. I'm spending a lot of time trying to plan this thing out so I don't get hit with a gotcha as I do still have a day job and can't quit it until I've released something that does well enough to cover the loss of pay. Don't get me wrong, I plan to support this app for as long as iOS exists, I just can't give 100% of my time making sure it's compatible.

 

[bjet767]

I'm in the process of writing my first App that I will publish to the App Store (Xcode 8, iOS 10)

Fantastic!

My first app, a very simple one that accessed corporate internet and data for internal users, took about 6 months to develop, test and get to the App Store. I'm currently finishing an extremely complex app for one one of my personal passions and have been developing and testing for about two years. It uses BT, iCloud, location services, Apple Watch and some more features.

The reason why I'm writing this is to let you know my experience with iOS is this, it grows and becomes more complex as you dream about features and usability.

I noticed that you are having difficulty with the constraints, the only advice I can give is to practice and test. Layouts are a pain.

If you need a portable database engine iOS does support SQL Light and that is cross platform transferable.

Enjoy!

 

[mildocjr]

Fantastic!

My first app, a very simple one that accessed corporate internet and data for internal users, took about 6 months to develop, test and get to the App Store. I'm currently finishing an extremely complex app for one one of my personal passions and have been developing and testing for about two years. It uses BT, iCloud, location services, Apple Watch and some more features.

The reason why I'm writing this is to let you know my experience with iOS is this, it grows and becomes more complex as you dream about features and usability.

I noticed that you are having difficulty with the constraints, the only advice I can give is to practice and test. Layouts are a pain.

If you need a portable database engine iOS does support SQL Light and that is cross platform transferable.

Enjoy!

I'll keep SQLite in mind, it does appear to have a licensing cost which I'm trying to avoid at this time, possibly the better solution would be firebase as it is initially free and scalable. I used to be a cloud admin so I'm a huge fan of scalable services. Since this app may have a possibility of running without a data connection I may end up running Core Data just for local storage when the network is not available and replicating this data out to Firebase once a month. So my process layout is looking something like this:

This way Firebase will be the primary sync only has to update the data once, then the app can check if core data has the data and if not it can seed it with the Firebase data. As much as I don't want to integrate two data models it will can help limit the amount of data I transfer by checking the json document date in Firebase against the document date stored in Core Data, to keep bandwidth lower on Firebase (might keep me in a lower tier for a longer period of time.

 

[bjet767]

For small local files core data is a waste of effort the only caveat is iOS file system limits you to the app's sandbox or iCloud. There are some ways to write/send files to external, non-device, URLs.

I use UIDocument for iOS and NSDocument for OS X when my data grows beyond the simple because these handle all the file io quite well. No writing of read/write functions, just sub-class and work with you data streams.

Additionally you've probably found that iOS has some objects with native handling of json built in.

Enjoy!

 

[mildocjr]

For small local files core data is a waste of effort the only caveat is iOS file system limits you to the app's sandbox or iCloud. There are some ways to write/send files to external, non-device, URLs.

I use UIDocument for iOS and NSDocument for OS X when my data grows beyond the simple because these handle all the file io quite well. No writing of read/write functions, just sub-class and work with you data streams.

Additionally you've probably found that iOS has some objects with native handling of json built in.

Enjoy!

I plan to use core storage for local archiving of content. The JSON file I'm parsing has almost 1900 entries each with roughly 13 items (1.3 Mb file size) so when thinking about my options Core Data seems like a good option. I'm fairly new to storing data in iOS, but I want to be easy going with data usage and I want quick (O(1)) data retrieval. I figured as close as I could get was an indexed database. I'm not too concerned with the weight of my app as the end result will be relatively small, the more I can generate using CoreGraphics the better.

This app will be designed for users going out of the country and coming back. While they are in the country I want the JSON data to be downloaded, but as soon as they are off network I want to rely on CoreStorage for saving the data until they are on WiFi. The JSON is only necessary when they are in country so I have no problem relying on Firebase, but I need a local storage option to save the user specific data until they are in an area where they won't get charged fees over international roaming. As far as iOS having other objects with native handling of JSON, I may have seen them but wrote them off as I may have thought I needed to have the JSON serialized first.

For now I'm using SwiftyJSON to parse the data and moved it to [structname]. I just need to get the data to persist so I only have to check the json["CreatedDate"] property to see if the JSON that was downloaded is newer than what is currently persisted on the device. Of course if this could be done in a data stream that would be more optimal that downloading the entire file, but I have not come across a method that works like this for what I know about downloading data.

It probably doesn't sound like it but I'm having a good time with the development process, as my first project I'm getting stuck quite a bit, but most I can hash out what's happening and refactor, while other stuff like this, I'm finding Macrumors to be much more beneficial than Stack Overflow. Kudos to you guys and gals.

 

[bjet767]

Using core data does allow for sorts and relationships of data and if that's what you need it's built into iOS and OS X.

Since I don't need a relational database with my current project I store real time data retrieved from devices off Bluetooth just using NSMutableArray of a subclassed NSObjects that represents the data collected and stored in a subclass of UIDocument. Typically I average about 6500 objects (records) in the recorded event and Local storage is a non issue and a 1.5 meg file is nothing.

You can choose to store in the app's sandbox or the user's iCloud, but I would imagine your users do not need direct access to your file via iCloud, so just storing it locally is enough.

What you could do to update the file is to build checks in the app to see if it is connected to wifi and therefore the net for file updates and schedule those updates to happen in the background. And that brings up another issue , you have to configure the app to work in the background and sometimes that can be frustrating. iOS for battery life restricts background operations and Apple discourages continued background tasks. In fact if you are not using certain background services iOS will eventually suspend the app, you may even get an App Store rejection if you try to force things outside of Apple's policies in this area.

I would check github to see where others have gone before you in these areas. Great resource for code.

 

[mildocjr]

Using core data does allow for sorts and relationships of data and if that's what you need it's built into iOS and OS X.

Since I don't need a relational database with my current project I store real time data retrieved from devices off Bluetooth just using NSMutableArray of a subclassed NSObjects that represents the data collected and stored in a subclass of UIDocument. Typically I average about 6500 objects (records) in the recorded event and Local storage is a non issue and a 1.5 meg file is nothing.

You can choose to store in the app's sandbox or the user's iCloud, but I would imagine your users do not need direct access to your file via iCloud, so just storing it locally is enough.

What you could do to update the file is to build checks in the app to see if it is connected to wifi and therefore the net for file updates and schedule those updates to happen in the background. And that brings up another issue , you have to configure the app to work in the background and sometimes that can be frustrating. iOS for battery life restricts background operations and Apple discourages continued background tasks. In fact if you are not using certain background services iOS will eventually suspend the app, you may even get an App Store rejection if you try to force things outside of Apple's policies in this area.

I would check github to see where others have gone before you in these areas. Great resource for code.

Great response, really puts my situation into perspective. The data I'm using comes from GitHub, as I haven't found a function to check for the creation/modified date in the files metadata, but the file does come with a CreatedDate property, I was thinking to parse the file server-side, extract the CreatedDate and create a flag to reduce network activity.

I don't plan to use background services at all until v2 of the app when I start connecting users together and including notifications for messages. I would like for the app to suspend in the initial release. My goals are to keep background and network activity to a minimum. I'd rather have my servers do a little bit of processing to optimize the data flow than use up network like there's no limit. I've even started thinking about just putting flags for what has changed and only sending the updated data to the devices to further limit network. Since the demographic of my users will involve international travel during one of the phases, I plan to cut cellular connections out until they return. As the data contains a list of locations that may not change very often, I plan to only update the information once a month.

So far Github and Stacksocial have been great with pre-existing code that I've been able to customize into my app, however, I'm quickly learning the conceptual things from here.

I feel like I went from `Hello World` and `Recipes App` straight to `Apple Store App`. It's definitely a challenge! Thanks for the advice and I can only hope that when I publish it my logic is sound and Apple is kind.

 

[Dookieman]

So, like others have said, use Core Data and create NSManagedObject's to store and Model your data. Core Data is incredibly powerful and fast and using Model that utilize NSManagedObject will make your life very easy. NSUserDefaults are meant for simple things, like Settings or Preferences. If you stick that much data into it, it will be very slow since it's really just a .plist behind the scenes.

Overall, sending 1.3 megs of data isn't much, I wouldn't be to concerned about cellular data plans if you plan on only updating the data once a month. You could even do it more often by versioning the data. (e.g. Only sending out the differences in data based on what the current user has.)

It's common to use Interface Builder for quick mock-ups, but why stop there? You can design the whole UI and flow within IB. Personally I feel keeping track of all that gets out of hand quick. I personally like using IB to build the UI but control the flow programmatically rather than set segue's in IB.

 

[mildocjr]

Overall, sending 1.3 megs of data isn't much, I wouldn't be to concerned about cellular data plans if you plan on only updating the data once a month. You could even do it more often by versioning the data. (e.g. Only sending out the differences in data based on what the current user has.)

I'm only making it a concern as my current goals are to restrict cellular data by date instead of region as my intended users WILL be leaving their service area. I'd hate for my app to be on the front page in a criminalizing article because I was trying to pull 1.3 MB down ever so often while the users are in International roaming. I'd probably be facing a lawsuit in the first few months and the app downloads would screech to a halt almost immediately.

It might help to understand that this app's demographic is for military soldiers who may, I know I used will above, use the app during their deployment. Yes I could just use CLPlacemark and check to see if they are within their country but that would require a constant check for location and I'm trying to be friendly to battery life. Plus, since I am assuming GPS runs up data, I really don't want to be checking when they are out of their country. Even one check makes me cringe considering a 30 minute phone call in Kuwait on AT&T costs $875 (from experience).

The app is meant for soldiers going on or having returned from a deployment. It has specific use cases in the before, during, and after states. I'm just trying to tip-toe around the during stage without removing Wi-Fi connections for data syncing between devices and not just JSON data. The JSON is just a tip of the iceberg compared to the rest of the data that I want to send and the frequency in when its sent.

Even if the user has an international plan, I still want to ensure that I'm meeting the policies put in place by some governments that cease all communications when a soldier is killed between deployed soldiers and their families until the deceased family is notified through their government's procedures. Blocking access to cellular is how I plan to do this as Internet connectivity will be disconnected at the base level and will kill WiFi anyways.

 

[bjet767]

That last post just upped the complexity of what you seek to do. But here's a couple, okay a few, things to think about.

1. Apple iOS is extremely good about not using data from roaming unless the user agrees to it.
2. iOS will not sync with other iOS devices and exchange files unless the user has some sort of cloud service set up that will allow that.
3. Bluetooth file sync is almost impossible with the exception of "sharing" files between devices. Best example is photos. You can set up your file and have it added to shareable files, however I have not done that and therefore I am unable to suggest how it's accomplished.

iOS is a very robust and featured filled API so use every object you can and try not to reinvent any wheels.

Wait till you get into animation. That's a whole new world in iOS and the word "layer" will become your friend.

Oh the GPS and location services will function just fine without any sort of data link. The only caveat is you will not be able to view a map until it can download the map data for the UIMapView to display. I have tracked locations for hours, saved the location data and then viewed the route as a map hours and days later without being connected to any data service while recording the GPS data.

Enjoy the road.

 

[mildocjr]

That last post just upped the complexity of what you seek to do. But here's a couple, okay a few, things to think about.

1. Apple iOS is extremely good about not using data from roaming unless the user agrees to it.
2. iOS will not sync with other iOS devices and exchange files unless the user has some sort of cloud service set up that will allow that.
3. Bluetooth file sync is almost impossible with the exception of "sharing" files between devices. Best example is photos. You can set up your file and have it added to shareable files, however I have not done that and therefore I am unable to suggest how it's accomplished.

iOS is a very robust and featured filled API so use every object you can and try not to reinvent any wheels.

Wait till you get into animation. That's a whole new world in iOS and the word "layer" will become your friend.

Enjoy the road.

1. I keep forgetting because I have sprint with unlimited roaming so I leave mine on although it feels like 28k dialup.
2. If I were sticking with iOS I'd just use CloudKit and sync with it during wifi connections, but as Firebase was mentioned it seems like a good way to go so I might jump on that train until a better option is presented. This is where I get most of my concern about network usage.
3. Bluetooth I do not plan to use at all, even if a soldier brings an iPad or I decide to create a Mac app, it would not be very beneficial from my standpoint except in the use case where Wi-Fi is not available and data should be synced back to the computer for a hardwired connection. If this isn't an automatic feature, I don't expect the code effort to usage ratio worthwhile enough to implement it. I'd rather just focus on getting my data compressed before I send it.

I think I have enough suggestions to go on for networking, any other scalable database solutions are welcome, and of course, if anyone has any other input on the order in which I should build the app, that's welcome too. I'm certain the UI is going the be the most lengthy implementation for me but possibly the easiest to learn.

Outside of that and for other new developers reading this, I've come to terms with breaking my project up into smaller Xcode projects, implementing the specific features there (mostly readability and focus) and then copying the swift file or code snippet into my project as a helper. Plus I'm getting the added benefit of lightweight easy to navigate through the code controller files. Unit testing is looking like less of a chore.

 

[Dookieman]

1. I keep forgetting because I have sprint with unlimited roaming so I leave mine on although it feels like 28k dialup.
2. If I were sticking with iOS I'd just use CloudKit and sync with it during wifi connections, but as Firebase was mentioned it seems like a good way to go so I might jump on that train until a better option is presented. This is where I get most of my concern about network usage.
3. Bluetooth I do not plan to use at all, even if a soldier brings an iPad or I decide to create a Mac app, it would not be very beneficial from my standpoint except in the use case where Wi-Fi is not available and data should be synced back to the computer for a hardwired connection. If this isn't an automatic feature, I don't expect the code effort to usage ratio worthwhile enough to implement it. I'd rather just focus on getting my data compressed before I send it.

I think I have enough suggestions to go on for networking, any other scalable database solutions are welcome, and of course, if anyone has any other input on the order in which I should build the app, that's welcome too. I'm certain the UI is going the be the most lengthy implementation for me but possibly the easiest to learn.

Outside of that and for other new developers reading this, I've come to terms with breaking my project up into smaller Xcode projects, implementing the specific features there (mostly readability and focus) and then copying the swift file or code snippet into my project as a helper. Plus I'm getting the added benefit of lightweight easy to navigate through the code controller files. Unit testing is looking like less of a chore.

Your last paragraph is a great approach and tons of experienced iOS devs do that same thing. I create a small project to learn how a new framework works or test different approaches to problems I am solving.

Good luck. If you have any more questions on how to approach problems feel free to message me or reply.

 

[mildocjr]

Your last paragraph is a great approach and tons of experienced iOS devs do that same thing. I create a small project to learn how a new framework works or test different approaches to problems I am solving.

Good luck. If you have any more questions on how to approach problems feel free to message me or reply.

Thank you, I appreciate all of the help and valuable insight you all have given me.

I'm looking through a few Swift tutorials and doing the project after I learn new techniques. I'm at the phase where I'm leaving book smart about Swift and becoming a functional programmer. Right now, since I'm doing this entire project solo, I'm planning a Veterans Day 2017 release date. I figure this gives me about 1 month to plan and implement UI and UX, 6 months to write the initial code + unit tests, 1 month for refactoring + unit tests, 1/2 a month of closed alpha testing for bugs, 2.5 months for public beta testing for bugs and improvements (also gaining a feature list to start implementing for v1.1) and a month to get my submission into Apple (without rejections).

Since I plan on using a lot of text, I'm considering just writing it out in documents and including those with the app, then fetching the content from those files when I need them. I figure this way app maintenance will be much easier in the future. Nothing super secret for those who want to break into my app contents, so I'm not worried about including plaintext seed data with the app.

If you know of any good websites that give examples/tutorials of good App design, I'll be happy to sponge those up too.