I think one the biggest sticking points for Apple is the slow pace of new feature/fix prorogation if there are more layers added to the stack. If Apple had a new super-slick X feature and they had allowed Flash/Silverlight/Java/Whatever, applications made with those secondary layers that wouldn't implement X until Adobe (Microsoft, Oracle) updated their stuff and users installed it in sufficient numbers. That lag moves control of innovation out of Apple's hands and into Adobe's or Microsoft's, giving their competitor's a nice big lever to squeeze Apple if needed. Those who've been around a while know that this game has been played many times before where key technologies were lacking or late on the Apple platform, driving customers to competing systems. I think Apple was pretty smart this time to make sure they hold all they strings on their new platform. Sure that means they can also abuse their powers to the detriment of their own developers, but that's sticking it to themselves if they go down that path.

Add in that historically all cross-platform development environments have generally been used to churn out the lamest of packages and generally end up favoring one (non-Mac) platform anyway. Why would anyone want that? The converse is that the best packages always end up being custom built for a particular platform in that platform's best IDE. At least I'm not familiar with any exceptions.

CB

Bryan Smart wrote:
While I agree with your FSF software freedom philosophies in general, the 
reality is that, had the iPhone and iPad been free/open, it wouldn't be as 
stable or as accessible.

Apple has lots of technology related rules about how you can develop your 
program. While there are lots of rules about what you can't do, and what tools 
and techniques you can't use, they all stem from people wanting to build 
software in a way that goes against Apple's design for the iPhones/iPads. 
Apple's design is to have a platform that is stable, that is free from rogue 
software, and that is intuitive and consistently operated. Your software is 
intended to be written in C, C++, or ObjectC, and isn't intended to use APIs 
that are any higher or lower level than the Foundation and UI kit frameworks. 
That isn't some plan to ruin your business possibilities or shut down your 
freedom. That is a deliberate decision that is intended to avoid the traps that 
most other smartphones and PDAs have fallen in to. The I devices have been 
successful specifically because of this approach.

I think that we had a discussion about iPhone/iPad development languages here 
already. The reasons for requiring C/C++/ObjectC are because of performance. 
The I devices use a 1Ghz or less processor with practically no cache memory and 
a slow memory controller. They have way less computational power than a 1Ghz 
desktop processor. They would be terrible at running interpreted run-times for 
high level languages. The lack of interpreted run-times is why the I devices 
seem to run so much faster than the Android devices, which have practically all 
of their applications written in Java.

Another problem with run-times is that Apple would become dependent on them for 
the software that they host. if Apple needs to change a small part of the 
Foundation or UI kit frameworks in an OS update, then this would only break the 
few apps that used those features, and only until they could be updated. If a 
change like that broke a run-time, Apple would be blocked by Adobe or another 
run-time provider until they could update their run-time. We know how eager 
Adobe hasn't been to do anything about flash on the Mac desktop. I suppose that 
this, among other lessons, taught Apple that they can't afford to be ignored by 
a 3rd party developer.

Even if the problem with updating run-times didn't exist, run-times would make 
the accessibility situation worse for us. As things stand today, if you want to 
create an app for an I device, you must create it from scratch, targeted 
specifically to the I device, and must use Apple's standard APIs. If Apple 
permitted high level languages and frameworks, then we'd have a lot of apps 
that were simply ports from other platforms with a user interface proxy layer 
to get their existing user interface to display on the I device. These 
attempts, no matter the platform, seem to always be profound hacks. The 
resulting interface never quite works like a native app's interface, and the 
accessibility is almost universally poor to nonexistent. It's no surprise, 
since, instead of having to use Apple APIs to do things like create a window 
and populate it with user interface objects, the developer's proxy layer is 
just as likely to create a window with a canvas object and directly draw their 
entire interface in to this single object. For sighted people, this means that 
the interface of these apps won't work as they expect. For blind people, it 
means that the app won't talk. Since I device apps must be written specifically 
for the I devices, and since the native UI objects have accessibility support 
inherently included, we get a fair amount of accessibility to an app, even if 
the developer didn't make any specific effort to make their app accessible. On 
my Symbian devices, there are lots of cross-platform apps that bypass the 
native user interface support, and do things their own way. That's partly why 
we have practically no accessible Symbian apps when compared to what is 
available on the I devices. The situation is very much the same on Windows 
Mobile.

Finally, Apple does compel you to use their compiler and dev tools, true. 
However, this isn't a play for your money, as everything, from the compiler, to 
the IDE, to the emulator, to the SDK are available for free. Forcing all apps 
to be built with their compiler means that they can adjust optimizations to 
code compilation in one place, and all apps will benefit. Since everyone will 
be building from their SDK app templates in Xcode, this decreases the 
likelihood that noobie developers will bork a compile flag and cause a 
performance problem or conflict.

As for code signing and the app store, I like this the least, but I understand 
that it's necessary for security and ease of software distribution.

When it comes to security, you'll never see any substantial malware or viruses 
on an I device, as, once an app like that is discovered, Apple can pull the 
plug on it everywhere. Further, you can't just be some anonymous developer of 
some freeware app and sneak malware on to I devices like that, since you must 
register for a developer certificate from Apple. A developer is far less likely 
to break the law if it is quite easy to discover who they are and prosecute 
them.

For software distribution, the app store is great. In exchange for a small fee, 
Apple helps people easily discover your app, pay you for it, and install it on 
their device. Anyone with a finger and a brain can find and install your app, 
even if they don't know squat about computers. Contrast that to how things are 
on a desktop, where they'd need to get a link from someone to a sight where 
they can purchase your app, fill out an order form or open a PayPal 
account/transfer money to purchase the app, download the app from your site, 
potentially unzip/decompress it, transfer it to/install it on their device, get 
an activation code out of e-mail, and input that in to the software. Besides 
being time-consuming, there are huge segments of the population that have no 
idea how to do such things. If you force them to know that stuff in order to 
buy from you, you've dramatically shrunk your potential market down to only 
computer-literate people, rather than anyone with an I device.

Even if most people can struggle through this task, they're still going to e-mail you for 
technical support with "how do I unzip a file? how do I download? The download link 
didn't work. I tried to connect my I device to transfer the app, but I got an error 22134 
no data connection present error? The code that you sent me didn't work. I never got the 
code. Or similar." The app store gets rid of all of that. Finding, purchasing, and 
installing is brain-dead simple. And, if they need to reformat their device, the app 
store knows that they own the app, so will let them re-install. They won't be e-mailing 
you on a quest for help downloading and installing the app again, or getting you to look 
up their activation code because they can't find it. Apple's little fee they charge, and 
the app store approval headaches, are so worth not having to worry about all of this 
end-user support junk. All you have to do is to code and test. If you code to Apple's 
user interface guidelines, you usually don't even need to document, since it will be 
obvious to people how to operate your app.

Finally, the locked down nature of the I devices, and the code signing, means 
that the I devices have really good copy protection. There is no 100% perfect 
copy protection, but the I devices are damn close. Since most everyone that 
uses your app will have paid for your app, since you won't need to spend your 
own money licensing copy protection, and since you don't need to spend time 
paying for people to handle support, or else wasting your own time handling 
support, you can actually afford to charge little prices like $5, and actually 
make enough money to make the time spent programming worth it. If you had to 
handle distribution, payment processing, and support, if you had to license 
copy protection tech, if you had to do any of those things the app store does 
for you, you'd need to increase your prices just to cover those costs.

I think that the rules regarding app approval need to be more clear than they 
are now, and less subject to whim, but I don't begrudge them the technical 
limitations. The other smartphone/PDA manufacturers that are still working 
under the older approach of letting people write software any sloppy and hacked 
way that they want, letting anyone install anything that they'd like, and 
forcing people to know about download links/activation codes/etc in order to 
install apps have devices that aren't as stable and don't have nearly as much 
quality software.

I learned to program on an Apple II, where we had complete hardware 
specifications and detailed firmware references and disassemblies. I obviously 
liked to tinker. Today, though, it is more important to me to have hardware and 
software that I can depend on to operate correctly. With the spammers, hackers, 
and hordes of third-rate software developers out there, it is looking more and 
more obvious that, without technological restrictions, those people will 
continue to, through malice or neglect, use our open computing platforms 
against us. Unless you want to learn a lot about working on a computer, which 
most people don't care about at all, a device with technical restrictions that 
serve as security and quality control barriers is a far more preferable choice. 
People that aren't computer-literate are a majority of the population. I think 
that they're going to eat up devices like the iPad. Very soon, the technical 
people on their general purpose computers may find themselves to be in the 
minority.

Bryan

-----Original Message-----
From: macvisionaries@googlegroups.com [mailto:macvisionar...@googlegroups.com] 
On Behalf Of Chris Hofstader
Sent: Monday, April 19, 2010 8:02 AM
To: macvisionaries@googlegroups.com
Subject: Re: Apple regulating news and political content???


jp: Well this is a law suit waiting and begging to be picked up and
they will win it. This is going against the your US right as a
citizen. Called Freedom of speech and Freedom of Press! So I think
this is why Apple changed it mind This is like saying you can surf the
internet but here is where you can go and read and this it. This is
not right for adults. Now for children under the age of 18 this might
have some value. So they I think should say yes you can have it on the
store but because of the nature of the app you need to have some kind
of age verification. But this is my thoughts and I been around the legal system 
a long time.

cdh: First, a week or two ago, a court shot down the FCC regulation requiring 
net neutrality so ISP businesses can pick and choose what content they favor 
and either prevent or slow down other pages.

cdh: Apple, as a private company is not required to provide free speech to its 
developers on AppStore. You can read their developer End User License Agreement 
(EULA) on the EFF web site which is the most restrictive I've ever seen. If you 
want to get your program onto AppStore you need to follow its restrictions 
which, in the latest version, actually requires a specific development 
environment (Apple's of course) to write the program. While I consider Adobe to 
be accessibility poison, their new write once, run many development tools look 
pretty cool but one is banned from using them on Mac for AppStore.

cdh: Apple has a long history of bad behavior regarding software freedom, 
including aggressive patent stances, lawsuits against a whole lot of different 
organizations for a wide variety of often obscure issues and making their OS 
restrict to their hardware - thus making the whole thing more expensive.

cdh: Apple products have a lot of excellent stuff in them but the company 
itself can be pretty nasty.

cdh

Sign,
Joe Plummer ( JP )
joeplum...@tds.net

-----Original Message-----
From: macvisionaries@googlegroups.com
[mailto:macvisionar...@googlegroups.com] On Behalf Of ch...@q.com
Sent: Sunday, April 18, 2010 12:48 PM
To: macvisionaries@googlegroups.com
Subject: Fwd: Apple regulating news and political content???

I got this and thought it would be of  interest to some n the list.
Not sure  what I think yet.
Carolyn


      Mark Fiore's job is making fun of political figures. And he's
actually quite good at it, according to the Pulitzer Prize Committee.

      Earlier this week it named him the winner of the Pulitzer Prize in
editorial cartooning, but Apple rejected an iPhone app containing
Fiore's cartoons in
      December. The reason? Apple said applications that ridicule public
figures are not allowed.

      That presents a problem for Fiore, and all editorial cartoonists and
political satirists who'd like to submit their work to the App Store
for that matter,
      because, well, that's what they do.

      Luckily for Fiore, the Nieman Journalism Lab took up his cause and
wrote about his app's rejection. A day later Apple relented, and on
Friday asked Fiore
      to resubmit. The New York Times reported Friday afternoon that Steve
Jobs himself called it "a mistake that's being fixed." That's great
for Fiore, but
      not every political satirist is a Pulitzer winner who can get
publicity for his app's unfair rejection.

      So what does that mean for the future of news or editorial products
on the iPad and iPhone? It's safe to assume that quashing political
satire isn't Apple's
      goal here. But it's a legitimate concern for the journalism community
that to be featured on the App Store they have to submit their news
content to a
      company unafraid to exercise what sometimes seems like arbitrary
control. The thinking goes, what if Apple finds a headline offensive?
Or what if there's
      an unfavorable article about Apple itself even? That's not to say
Apple would do that, but its inconsistent handling of App Store
submissions sets a troubling
      precedent.

      The rejected-then-unrejected brouhaha surrounding Fiore's cartoon
app, and others like it--the Mad Magazine artist's Bobble Rep app
comes to mind--also
      illuminate the central issue facing Apple with the App Store right
now. The company's decision to tightly control what is and is not
allowed on the iPhone
      or iPad has led it to develop a review process that is not
sustainable.

      Having individuals look at each one of the hundreds of thousands of
apps that pour into the App Store and accurately and consistently
police them for both
      technical and content issues is impossible now and will only be more
so as the App Store inevitably grows. The solution would be to have
clear, stated
      rules of what can or can't be put on the App Store, but that's not
what Apple has chosen. And that gray area is what scares developers
who put a lot of
      work into their apps, and who could be rejected outright for some
subjective problem an App Store reviewer has found with that particular app.

      Which brings us back to the news issue. The problem of Apple's lack
of transparency with App Store rules and tendency toward control is
compounded by Apple
      luring the print news industry to the iPad. It's a device that
(rightly or wrongly) is being praised as a way to save print publications.
And that control
      inevitably raises new questions about Apple's relationship with
newspapers, like The New York Times and The Wall Street Journal for
example, that are putting
      their content on the App Store via paid applications.

      The Columbia Journalism Review has issued a call to media companies
not to get too cozy with Apple. Writes Ryan Chittum:

      Look, let's face it. The iPad is the most exciting opportunity for
the media in many years. But if the press is ceding gatekeeper status,
even if it's
      only nominally, over its speech, then it is making a dangerous
mistake. Unless Apple explicitly gives the press complete control over
its ability to publish
      what it sees fit, the news media needs to yank its apps in protest.

      Yes, this is that serious. It needs to wrest back control of its
speech from Apple Inc.

      The CJR then points out the obvious: newspapers and magazines
wouldn't put itself under the influence of the government like this,
so why is a corporation,
      especially one with control-freak tendencies like Apple, any
different?

      If the iPad does become a significant revenue source for print
publications who turn their newspapers or magazines into iPad apps, it
is logical that it
      could be harder for them to stand up to Apple.






--
You received this message because you are subscribed to the Google
Groups "MacVisionaries" group.
To post to this group, send email to macvisionar...@googlegroups.com.
To unsubscribe from this group, send email to
macvisionaries+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/macvisionaries?hl=en.


--
You received this message because you are subscribed to the Google Groups 
"MacVisionaries" group.
To post to this group, send email to macvisionar...@googlegroups.com.
To unsubscribe from this group, send email to 
macvisionaries+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/macvisionaries?hl=en.


--
You received this message because you are subscribed to the Google Groups 
"MacVisionaries" group.
To post to this group, send email to macvisionar...@googlegroups.com.
To unsubscribe from this group, send email to 
macvisionaries+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/macvisionaries?hl=en.


--
You received this message because you are subscribed to the Google Groups 
"MacVisionaries" group.
To post to this group, send email to macvisionar...@googlegroups.com.
To unsubscribe from this group, send email to 
macvisionaries+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/macvisionaries?hl=en.

Reply via email to