[not quite OT] Serving a standalone

[Richard Gaskin]

William Prothero wrote:

 > Richard and Kay:
 > Thanks for the stimulating thoughts.
 >
 > Each of your arguments are very persuasive. And it seems that the
 > most important thing is where you decide to start. If you focus is
 > on mobile, Kay’s approach is the most sensible. I like Richard’s
 > for desktop, but would expect to have to modify it to get it on iOS.
 >
 > Re-iterating the two approaches:
 > 1. Make iOs apps and create enhancements, like say “myApp basic”,
 > “myApp Plus”, “myApp Pro”, etc. This means you would probably have
 > a bunch of apps in the store with a common code part and a
 > specialized part.
 > 2. Make desktop app with Splash system, like Richard uses. Later,
 > going to iOS would mean combining bits of the various pieces that
 > get downloaded by the Splash app into a single app for iOS, and
 > eliminating features unacceptable to Apple.

Kay's point is an important one, but the two approaches aren't mutually 
exclusive.

It's very true that many school districts today are embarking on the 
same sort of OS vendor lock-in that used to drive Apple fans crazy just 
a few years ago when districts purchased Windows exclusively.

LAUSD's district-wide iPad rollout may be a good example, though after a 
$1.5-billion-dollar "unexpected" cost overrun the contract has since 
fallen under federal investigation, and the superintendent has resigned.

Maybe it's not a bad example at all:  the current LAUSD plan is to 
diversify not only vendors, but also OSes and even form factors.  Right 
now their purchasing plans include a great many Chromebooks, which not 
only provide arguable benefit for more intensive workloads by having a 
built-in keyboard that doesn't diminish available screen size by nearly 
half, but are also significantly less expensive.  These are among the 
many reasons that while tablet sales have leveled off in the US an EU 
over the last year, Chromebooks have emerged as the highest-growth 
segment two years running.

In a world increasingly enjoying the interoperability of modern OSes, 
LiveCode can help by covering more platforms than most development 
alternatives.

But when exploring desktop vs mobile, you'll need to make different 
layouts for each anyway, so why not do both?

I've not seen your app but have been familiar with your work for several 
years, and it seems you have a solidly viable desktop product.

Any new product for iOS will take considerable effort to complete, 
because even though you can share a lot of the core business logic 
between your desktop and mobile versions you'll need an entirely new UI 
for mobile.

So you could start with what you have, refining the desktop product as 
practical to take advantage of things like downloaded stacks, and that 
revenue could fund the UI rewrite needed for iOS, which would also 
likely require using only local on-device stacks, and Apple's slower 
update system.

How you coordinate differences between a desktop version that downloads 
stacks and a mobile version that accesses them locally involves 
specifics I couldn't advise on without knowing more about the app itself.

But in general, given the amount of work needed for a mobile version, if 
you factor stack access through a library that determines whether it 
gets it from a server or a local file, either way the stack itself it 
still a stack, and once loaded from that point on it doesn't matter all 
that much how it got there.

-- 
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  Ambassador at FourthWorld.com                http://www.FourthWorld.com