[not quite OT] Serving a standalone
ambassador at fourthworld.com
Mon Feb 9 21:28:05 CET 2015
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
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
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
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
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.
Fourth World Systems
Software Design and Development for the Desktop, Mobile, and the Web
Ambassador at FourthWorld.com http://www.FourthWorld.com
More information about the use-livecode