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

Adrionix

macrumors newbie
Original poster
Dec 20, 2015
6
0
Dorset
Looking for some advice, I am new to the app game and have teamed up with a local tech company to build our 1st app. There experience in the app department is limited but they have a coder with some android experience and he is using xamarin to build native iOS & Android versions.

It's a peer to peer app.

Our coder started working the back end and front end coding in September but we never consulted any UI or UX designers as we were told this is something that can be done at the end.

After a bit of research I have found that it may be very important to involve these designers asap.

I am trying to figure out what cross over there is with UI/UX & coding.

Shouldn't the UI/UX design been involved at the initial stage? Will the code (3 months worth & very basic format) that exists now need scrapping and recoding to suit the design of the app?

Could someone explain in simple terms the best way to build an app from start to finish based on some detailed wireframes we have!

Would really appreciate it

Many thanks
 
IMO it all depends on the specifics, and how the work that has already been done is structured! If the developer adheres tightly to an MVC approach, replacing the UI should not require throwing out any back end "model" code. However if the model doesn't provide the required I/Os for the UI, you might have more issues.

B
 
  • Like
Reactions: grandM
I agree with the mod that applying MVC will decrease the need of involving an UI/UX developer from day one. However I think that the involvement ought to be from an early moment on. Otherwise you simply will loose a lot of time redesigning the views.
 
Otherwise you simply will loose a lot of time redesigning the views.
Or even worse, the model.

I've run into this a lot with many of the projects I work on. Someone decided that some information be hidden in/by the model and when developing the views that becomes apparent.

I'm personally a big believer in working the problem from both ends as soon as possible!

B
 
  • Like
Reactions: grandM
Ok that's really helpful thanks.

Would you say xamarin has any/many disadvantages when building native apps for android/iOS?
 
Ok that's really helpful thanks.

Would you say xamarin has any/many disadvantages when building native apps for android/iOS?

This is probably not the best place to ask about xamarin. Most of the people here use Xcode for building iOS apps. Some of us (me & at least a few others) use Unity.

From what I've seen, xamarin and most other tools for making an android and iOS version both at once output crap. Might just be that the people who use the tools are crap, but I can't help but the think the tools themselves are at least partially to blame.
 
Ok that's really helpful thanks.

Would you say xamarin has any/many disadvantages when building native apps for android/iOS?
Being dependent on any 3rd party tool will have at least one disadvantage. You'll be dependent on them providing support and updates. You'll have to decide for yourself what risk that would be. You mentioned that this is a game, is there a reason you aren't using Unity?

Another downside might be having full support for other things that come up. Example: if a new spec comes up and you want to support it, yet the 3rd party tool doesn't.

Another is what language is supported and any costs there might be if you need someone else to take over the building of the app.

Again, really have to dig into the product to see their support history.

Advantage: you cut cost on writing code for 2 or more platforms. The language used could be more popular or it might have more language choices.

One other note: Development style and tools can change depending on how complex the project is. You might want to consider how many levels and overall how complex the game will be.
 
Thanks KarlJay

It's not a game it's more of a peer to peer app.

I will definitely use this advice to Carr out the appropriate research and I can now ask the right questions so many thanks
 
It's a really, really bad idea to work on the app if the UI isn't finished. The reason is that a new UI usually results in significant changes to the way the data model works (or should work). It's also usually faster if the model is designed to serve the view controllers from the very start. If you know exactly what kind of method you will use to present data (ie. on a table) you can design the model around this.

It's important that the app is modular, the MVC approach usually ensures this. But the model won't live in a vacuum, its only purpose is to serve the UI. And it's hard to design a good model without knowing what the UI will look like.

It also saves you from a lot of extra work. If they start working on the app before the UI is designed, they will likely create a temporary UI just to test the model, but this will waste a lot of time since they could have just started with the UI in the first place.

I've always been a fan of designing the UI and the data model in concert, it's the fastest and simplest way to develop an app. Unless your app is being created by a large team of coders, where every single tiniest detail has been planned out to an exquisite level of precision, you're going to end up wasting a lot of time unless the UI is finished first.
 
  • Like
Reactions: grandM
That's what I feared, well at least we have established the issue early on and can take the appropriate course of action in the new year!

Some great responses

Another question- is it difficult to find a coder in the uk (cross platform capable) with experience and hire hem to work within a tech team on a salary & if so roughly what would we be looking at per annum?
 
For simple apps, you can get away with almost any approach. You'll probably find that apps can become complex in different areas.

Example:
You can have an app with a simple UI and complex code "under the hood".
You can have an app with a complex UI and simple code "under the hood".

I would tend to examine the needs of the most complex part of the app first so that you have a clear understanding of what the project will demand.
 
That's what I feared, well at least we have established the issue early on and can take the appropriate course of action in the new year!

Some great responses

Another question- is it difficult to find a coder in the uk (cross platform capable) with experience and hire hem to work within a tech team on a salary & if so roughly what would we be looking at per annum?
If you ask me it's better to hire two developers for instance for iOS and android. Chances are it's easier to find people specialized in one topic then in both. I also think you ought to consider remote work. I never understood why IT should be done locally. Ok you must keep in touch on regular basis but I wouldn't confine myself to a country.
 
  • Like
Reactions: ArtOfWarfare
That's what I feared, well at least we have established the issue early on and can take the appropriate course of action in the new year!

Some great responses

Another question- is it difficult to find a coder in the uk (cross platform capable) with experience and hire hem to work within a tech team on a salary & if so roughly what would we be looking at per annum?

Usually getting someone that is native and cross platform cost more. In addition, getting one that is 3+ years, costs even more. It's really a supply/demand issue.

The market is still high growth and expected to be for a good while. You'll find plenty of new people for entry level programming and that could work for a simple project. Larger more complex projects should require more background in larger projects.

I'd check the local job boards, I don't know how active UK is in programming, I've heard the whole EU is a bit behind the tech curve compared to the USA.

I'd also be concerned about those that don't really study programming or software development. Some just see programming as something they have to get through in order to make their app. Others study the language and understand the science of computer programming. It's hard to tell them apart without looking at their code for a complex project and seeing if they are a "cut-n-paste" example code programmer, or if they can create real solutions to complex problems.
 
If you ask me it's better to hire two developers for instance for iOS and android. Chances are it's easier to find people specialized in one topic then in both. I also think you ought to consider remote work. I never understood why IT should be done locally. Ok you must keep in touch on regular basis but I wouldn't confine myself to a country.

+1 on asking for too much. Some want a "full stack" programmer and that can be a mistake.

As far as local vs online programmers, there's been a ton of scams with online / contract programmers. It's not so easy to keep good control of things and insure you don't get ripped off with a contract programmer. Enforcing laws against someone in another country isn't so easy or cheap. Plenty of horror stories out there. Do some research before you buy.
 
General UI (a rough mark-up) -> App code (Model) development -> Final Design commit

IMO, your data model should dictate the structure of your app, not the design; you should be able to isolate your data model into a framework (with iOS specifically) and port it between yours various apps as a "black box".

Going to say that you need an Android and an iOS developer, or someone who is willing to code two separate apps independently. You won't get a good app but avoiding UIKit and Android UI.

I'm going to go a step above what other people say about modularization, too, and suggest you find a developer, specialized in iOS, who is knowledgable of MVVM forms of development. It's far superior to anything Apple will suggest and I find it highly likely they'll encourage this type of development once they find a suitable way to mock out the various method calls like Reactive Cocoa did (and if you look at the evolution of Swift, we will be seeing this).
 
General UI (a rough mark-up) -> App code (Model) development -> Final Design commit

IMO, your data model should dictate the structure of your app, not the design; you should be able to isolate your data model into a framework (with iOS specifically) and port it between yours various apps as a "black box".

Going to say that you need an Android and an iOS developer, or someone who is willing to code two separate apps independently. You won't get a good app but avoiding UIKit and Android UI.

I'm going to go a step above what other people say about modularization, too, and suggest you find a developer, specialized in iOS, who is knowledgable of MVVM forms of development. It's far superior to anything Apple will suggest and I find it highly likely they'll encourage this type of development once they find a suitable way to mock out the various method calls like Reactive Cocoa did (and if you look at the evolution of Swift, we will be seeing this).
I just looked MVVM up. Isn't that the same as MVC?
 
Not entirely.

On iOS, controllers tend to encapsulate a lot of model logic, handle callbacks (delegations, KVO, NCenter, the list grows), and coordinating views (and sometimes other VCs). MVVM is meant to be a subset of the MVC pattern that breaks away the two former responsibilities into encapsulated "View-Models", essentially to act as glue between controller (which should only manage view elements) and the model (which is often spreading into controllers).

It's a very nice pattern: For example, my view controllers have no knowledge of my Model framework or even Core Data, making them smaller, more concise & reusable, and more of the logical flow of my application super testable.

Edit: Here is a nice introduction to what MVVM is, though the part about Reactive Cocoa is a bit outdated (they've made a major push into Swift and no code will be accurate, but the principal is exactly the same).
 
Last edited:
The whole MVC idea and every other idea like it is... IDK... Wrong.

You should understand the concept, get why it's useful, then... Not ignore it but... Don't follow it. It's not some kind of prophet or holy book or anything. It's more like a case study or something. Useful to think about when you're considering how to organize your code, but don't contort your code just to satisfy it.

99+% of the time, I find that it's best to put your "model" and "controller" in one freaking class. There's absolutely no value to spreading them between two or more classes. Do keep your views seperate - you'll want to swap between different ways of displaying the same data, but it makes no sense to keep your data and the valid ways of manipulating the data seperate from each other. If C followed MVC, you wouldn't be allowed to use operators on ints - you'd have to utilize the IntController to actually change its value. Sounds dumb? That's because it is, as is MVC.
 
The best programmers usually have great portfolios, you will want to closely look at that. Also if possible speak with their previous employers or look at ratings from previous jobs to get an idea of their expertise.

If you're looking to hire a rookie programmer, then good luck. Everyone was a rookie at some point but it's usually a big risk. Many of the contract programmers I have worked with really wasted a lot of time doing things inefficiently because that's how they learned how to do it in school. A good programmer can be hard to pick out from a bad programmer, the biggest difference is that the good ones usually have an obvious love of programming itself and do it even in their spare time.
The whole MVC idea and every other idea like it is... IDK... Wrong.

You should understand the concept, get why it's useful, then... Not ignore it but... Don't follow it. It's not some kind of prophet or holy book or anything. It's more like a case study or something. Useful to think about when you're considering how to organize your code, but don't contort your code just to satisfy it.

99+% of the time, I find that it's best to put your "model" and "controller" in one freaking class. There's absolutely no value to spreading them between two or more classes. Do keep your views seperate - you'll want to swap between different ways of displaying the same data, but it makes no sense to keep your data and the valid ways of manipulating the data seperate from each other. If C followed MVC, you wouldn't be allowed to use operators on ints - you'd have to utilize the IntController to actually change its value. Sounds dumb? That's because it is, as is MVC.
it shouldn't be taken to extremes of course but it's very very useful especially in big commercial projects. I just suggest having a general rule to keep your code as modular as possible within reason.
 
A good programmer can be hard to pick out from a bad programmer, the biggest difference is that the good ones usually have an obvious love of programming itself and do it even in their spare time.
Spot on! You can usually tell by if the code really show a deep understanding of the tools (language, API, etc). IMO, most will only do what it takes to get the job done and collect the paycheck. The sad part is that most businesses don't see the difference until it's too late and they then realize they've got a bunch of noobs and junk code.
 
99+% of the time, I find that it's best to put your "model" and "controller" in one freaking class. There's absolutely no value to spreading them between two or more classes. Do keep your views seperate - you'll want to swap between different ways of displaying the same data, but it makes no sense to keep your data and the valid ways of manipulating the data seperate from each other. If C followed MVC, you wouldn't be allowed to use operators on ints - you'd have to utilize the IntController to actually change its value. Sounds dumb? That's because it is, as is MVC.

I'm sorry, but this is absolutely horrible advice and shows a fundamental misunderstanding of the MVC concept.
 
Apple DTS strongly recommends you have a designer mock up the UX and UI, as a set of paper sketches even, before anyone starts writing UI or UX related code.

A coder who tells you otherwise has very little knowledge of mobile apps and what level of UX quality users expect these days. It's a lot more that pasting pretty icons on some techies idea of how an app should work.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.