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

kc9hzn

macrumors 68000
Jun 18, 2020
1,824
2,193
The first app you develop is the more expensive one. The thing is most of those companies already have a desktop app, this is why it is better to expose an API from the desktop app to use for the mobile app than to start from scratch. For example Office apps or Photoshop app. They have stared with desktop app and now they try to expose them to a mobile platform.

Lumafusion on the other hand stared with a mobile app. This is their business model and they are quite successful. They managed to create a rather nuanced and feature rich app that works great on a mobile device and takes advantage of the touch screen. To be honest I quite often I find apps that are not done properly to be used on a tablet or mobile device. It is like mini version of a desktop app with the same workflow that might make sense for a 15 inch screen with big keyboard and mouse, but does not make sense for a tablet or a phone.
I’d argue that good API design is a critical component of good system design and code re-use. Your mobile app should be able to operate on the exact same set of data objects as your desktop app. Say you have a word processor. Your mobile version should use the exact same objects, serialized in the exact same format, as your desktop version to the greatest extent possible. Your data objects should work the same when used on a remote server via a RESTful API, when SSHed into that remote server via the command line, when used in a GUI on your local desktop or laptop, when used on a GUI on a tablet, on your phone, or on your smartwatch or AR glasses. They shouldn’t understand anything about how they’re getting displayed, that’s just good separation of concerns.

From the view port perspective, a button on a desktop should ideally have the same behavior, regardless of whether it’s getting used in a file browser, a word processor, an image editor, or an IDE. Same goes for text fields, with the caveat that text specialty applications might need to inherit behavior from the existing text field but supply some specialized functionality. But not every text field needs to be custom, even in a word processor or IDE.

APIs help enforce proper separation of concerns, and both the desktop application and mobile application should be clients of the same API (should use the same data objects, which should expose the same data on all platforms). And the platform native UI elements should have their own APIs and should be able to be reused in a variety of locations. The custom code is the Controller code (in the Model-View-Controller paradigm) that is the client of both the data APIs and the view APIs, it’s the only code that should have a dependency on both view code and data code, and it’s where most of your platform+application specific code should live. But too many people write the app first and the API later. Just like how so many people write the function first and the unit test later, when it should be the other way around.
 

Mathias Denichi

macrumors 6502
Jun 21, 2013
454
637
Impressive to have the M1 for sure, but yeah, this is a great point. There really isn't a need with iOS as fluid as it already is, and it's not as if programmers can target the M1 directly since previous generation iPad performance would suffer (in other words, the vast majority of users heh).

Still, neat to see, but is it worth an upgrade? Nah... maybe the 12.9" for the display, but for the internals? Less obvious.
Programmers can target specific hardware in iPad OS now, its the reason why Luma Fusion will have more layers with 6gb of RAM, than an iPad with 2-4gb of RAM.

The iPad is forking similar to the Macbook Pros vs Macbook vs Macbook Air being able to run certain software better than others. IE: dGPU in a Macbook Pro 16" will run games better than the iGPU in a Macbook Pro 13", but both run MacOs.
 

rui no onna

Contributor
Oct 25, 2013
14,920
13,269
Programmers can target specific hardware in iPad OS now, its the reason why Luma Fusion will have more layers with 6gb of RAM, than an iPad with 2-4gb of RAM.

Caveat, I believe the 4GB RAM and 6GB RAM 2018 iPad Pros are treated the same. We don't know how 8GB and 16GB will be handled.
 
  • Like
Reactions: 007p

kc9hzn

macrumors 68000
Jun 18, 2020
1,824
2,193
I don’t think iPadOS micromanages memory usage like that, it’s more like apps can use as much memory as they need and can add layers until the iPad decides it’s using too much. Though individual apps may limit the number of layers you use for memory optimization reasons. I think that’s true on macOS, as well.
 

secretk

macrumors 65816
Oct 19, 2018
1,494
1,229
I’d argue that good API design is a critical component of good system design and code re-use. Your mobile app should be able to operate on the exact same set of data objects as your desktop app. Say you have a word processor. Your mobile version should use the exact same objects, serialized in the exact same format, as your desktop version to the greatest extent possible. Your data objects should work the same when used on a remote server via a RESTful API, when SSHed into that remote server via the command line, when used in a GUI on your local desktop or laptop, when used on a GUI on a tablet, on your phone, or on your smartwatch or AR glasses. They shouldn’t understand anything about how they’re getting displayed, that’s just good separation of concerns.
I agree with that. This is the design to go. I am not sure that an application that was created 20 years ago had that architecture from the start though. Most probably what happens is that the API was extracted afterwards. Either way this is usually good thing to do (despite going mobile or not) and I would expect most companies to have gone that road.
From the view port perspective, a button on a desktop should ideally have the same behavior, regardless of whether it’s getting used in a file browser, a word processor, an image editor, or an IDE. Same goes for text fields, with the caveat that text specialty applications might need to inherit behavior from the existing text field but supply some specialized functionality. But not every text field needs to be custom, even in a word processor or IDE.
From technical perspective yes, but I don't think that we can always have the same user workflow. There are certain aspects/activities that I would not do on a mobile app on a phone or on a tablet without hardware keyboard. Imagine exactly an app that requires entering manual data, working with a lot of fields to fill in or like I said entering accounting data. For me as an end user it is not about the API now, it is about the usage and the user experience. I just do not want to do that on a phone or a tablet without hardware keyboard. It is slow and inefficient for my expectations.

Another point is the UI itself. For touch screen you need bigger buttons that you can push with fingers. Now we have smaller screen, bigger buttons - this in itself requires changes to the user workflow. Sometimes tiny, sometimes big. For example our application is single page one, you have a lot of interactive components in one page. This does not fit with mobile, you need to separate them, this however also means changing the business logic behind because the nature of what we do, requires all info to be entered at once and reviewed at once by Accountants/Auditors. You naturally need to see all info in one place to be able to verify properly what you have done.

So this is what I meant when I said that sometimes the whole user experience and workflow needs to change to go to mobile.
 
  • Like
Reactions: kc9hzn

Maven1975

macrumors 65816
Aug 24, 2008
1,014
275
I think we all need to wait and see how the M1 performs in the iPad. - It may only be great in name with throttling and other trade offs.
 

Falhófnir

macrumors 603
Aug 19, 2017
6,146
7,001
I think Apple got some explanations to do soon justifying iPad Pro's 16 GB ram. Why are they selling 16 GB when the iPadOS is limited to 5 GB?
Multitasking is the simplest answer there, 5GB/app means you could easily use >8GB across 2 apps, and then need one ejected from memory if you're switching between them. While it hasn't happened this year, undoubtedly as iPad OS and it's apps creep forward there will be further demands on the memory. This was probably done now with an eye to 2-3-4 years down the line when most iPads will have 4GB+.
 

Digitalguy

macrumors 601
Apr 15, 2019
4,655
4,490
It should be noted that it's on a per-app instance basis, including those in memory.
5GB is plenty for a 8GB device. The thing is that until now Apple has made no RAM distinctions between iPads, so the apps cannot tell that a 16GB device has more RAM than a 8GB one, if they have the same SOC... If Apple does not change that (and they have not changed that since 2015, and I doubt they will) don't expect any difference in RAM limit per app on 16GB devices....
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.