If John Gruber is right and one of Apple's concerns is based on exclusivity
( http://daringfireball.net/2010/04/why_apple_changed_section_331 ), how would
we react if Apple's solution was to force our apps to be iPhone\iPad
exclusives?

What kinds of guarantees would be required for you to agree with it?  It
wouldn't take much for me, but I'd like to hear thoughts on it. :)

-a

That would be a tough sell. Sure Apple is big now - and going to get bigger
- but it would be really tough to say that this app is only going to be on
the iPhone. Some apps sure I could say that, but a line of business app or
an app the works with another system no. How would that exclusivity be
determined anyway? Name of the app? Functionality - there isn't a lot that
isn't done already - just different (and better) ways of doing it.



It is an interesting thought.



I think part of the terms change is a exclusivity issue, but I don't think
that's the only motive. I think they want to keep the UI consistent and
quality high across apps. They don't really want someone reinventing the
UITableView either. They want apps on the iPhone to behave a certain way to
have a similar look and feel familiar and comfortable to the end user.



My thought is that monoTouch follows this same thought pattern. Uses
Interface builder and encourages developing traditionally iPhone apps. It
just uses C# to do it instead of objective-c/c++/c .



To a great extent I understand Apple's thinking - I don't like it, but I
understand it. In a world where open source software is growing and big
companies are becoming more open and transparent and releasing big code
blocks under some type of permissive license it seems odd to go this far
backwards.



Here's to seeing how it all comes out in the next few days and weeks.

What Gruber discussed might be part of the picture, but I believe the  
truth is somewhere between these points:

o Apple wants developers to use CocoaTouch directly.
o Apple doesn't want Carbon or other third party framework to occur  
again (eg. Metrowerks had a C++ framework that was using Carbon as an  
underlying API)
o Apple wants to limit the accessibility and raise the bar of entry to  
ensure developers aren't cut an pasting code, making simple apps with  
no real effort or using an API layer that hides everything about  
CocoaTouch and Objective-C.
o Apple doesn't want third parties charging fees/proffiting to aid  
developers in creating apps.
o Apple doesn't want what would have been banned under the former  
rules (interpreted/VM based code) to game the system by passing itself  
off as native code.

Until Apple clarifies the points in more detail, I doubt we can be  
sure. Currently, anything not in Objective-C/C/C++ is extremely unsafe  
and might be destined to be rejected.

M

Sent from my iPhone

Sent from my iPhone

On 12 Apr 2010, at 06:18, Matt Emson <memson.lists*******>  

And to clarify "game the system", as I hit send by accident before  
doing so on review: creating a way for dvelopers to use what would be  
banned under the prior rules, had the code not ben altered/translated  
to some kind of native assembly language or Objectice-C. I'm willing  
to bet that if the app was translated once but and developer continued  
to develop the app in Objective-C, that might be an edge case that  
would maybe get past the policy. But developing in another language  
that is then translated on a regular basis would be prohibited.

M

Just read this:  http://bit.ly/bOFNg0

I'm getting pissed off with all this now. Any apple developer can say
what they want to make mt look bad yet we can't say a word for fear of
jobs going ape!!!

-----------------------------
e-wayne <at> isit.gd
t-07525 424 882

MonoTouch mailing list
MonoTouch*******/mailman/listinfo/monotouch

Thanks for the link - was a very interesting read.

Regards,

Chris

Unfortunately in that time I must make a decision to either move to
obj c, support both or stick with mt.'not an easy decision. And being
wise, I'd not take any chances. I really hate this situation.

-----------------------------
e-wayne <at> isit.gd
t-07525 424 882

And can I add, the thought of moving to an inferior, hacky, near on
untestable stack makes me feel bleaked out.

-----------------------------
e-wayne <at> isit.gd
t-07525 424 882

Completely agree - it is a difficult situation to manage and has certainly thrown my development plans into disarray. I am fortunately in a position where I can sit on my hands for a few weeks and see how the situation pans out before making a tough decision.

Regards,

Chris

I'm sure you'll appreciate this.
Especially this being the holocaust remembrance day here in Israel:


   Shechter.

Pure Gold!

I'm confused. After reading through the above linked post I'm left with a
sense of empathy towards non-Adobe development tools that are -- as the
writer suggested -- collateral damage of an overaggressive power move by
Adobe.  That's not to suggest I agree with each of the opinions presented by
Mr. Gerbarg, but I don't disagree with them either as I simply don't have
enough data to determine one way or another what's really going on behind
the scenes and what, if anything, can be done to help encourage Apple to
change it's policy in a way that allows room for third party tool vendors to
continue forward unimpeded. In fact, this is exactly the point that Mr.
Gerbarg makes close to the end of this post:

I would like Apple to find a way to work with the existing vendors who have

I'm not trying to side with Apple in any way, shape, or form in regards to
their decision to push forward with this clause. If for no other reason,
they have to have known that in doing so they would not only be painting
themselves with a Department of Justice bullseye but designing, contracting
out the manufacturing to China, to then install the war heads on the end
result of their "Designed in California" Cupertino-bound missels inside
their home turf labs in a last gasp effort to die with both dignity and
pride by the workmanship of their own narcissistic hand. And it's for this
reason alone I believe they have no intention of pushing forward with the
clause as it exists in its current form and instead using the time between
now and the final release of version 4 of the OS to put into a place a rigid
certification process that requires third party iPhone and iPad tool vendors
to both meet and adhere to a strict set of guidelines which would disallow
the injection of 3rd party design elements while requiring they pass a
performance benchmark suite designed to guard against memory, processor, and
battery hogging applications being given free reign over their otherwise
tightly controlled user experience.

In this regard I don't believe it's by some strange coincidence that we're
seeing this clause injected into the licensing agreement that covers the
first version of the OS to include the highly anticipated multi-tasking
support which Apple has been purposely holding back to allow battery and
processor technologies to catch up with the increased demand on system
resources brought about as a result.  Again, I don't agree with how Apple
has chosen to go about this, but I do recognize that negatively impacting
the core user experience is not something Apple has or will likely ever
allow and has subsequently built a long standing history of feverishly
reacting negatively against, whether that be stripping features from their
own in-house products or standing in the way of third party involvement that
threatens to undermine their reputation foundation in which Apple has been
built upon since day one.

--
/M:D

M. David Peterson
Co-Founder & Chief Architect, 3rd&Urban, LLC
Email: m.david*******
Office: (801) 924-8167
Mobile.SaltLakeCity: (801) 419-5975 Mobile.Seattle: (206) 999-0588 http://3rdandUrban.com  |  http://amp.fm  |  http://mdavidpeterson.com  | http://broadcast.oreilly.com/m-david-peterson/

With all due respect, that is FUD. Pure and simple. What you actually
mean is "I am unhappy that the Objective-C language isn't C# and/or
XCode tools aren't Visual Studio, so therefore I am not going to try to
use them." Having used the same tools since the days of Openstep, I
can't agree at all. For me, C# was a nice to have as that is my day job.
Objective-C was my legacy, as is Pascal - what I once used. I'm happily
reliving the halcyon days again with Apple's tool set, looking in at the
MT windows, wondering if the overly initial high pricing of the MT
product, that essentially priced me out of a purchase*, wasn't really a
blessing. *shrug*.

* I'm still here because I was holding out a hope that a cheaper SKU or
even virtually free "open source only" version would appear once the
product was more established. Most Apps I would be developing would be
for personal use, so that would suit me fine.

With all due respect. Dot notation kinda works here and there but not
really but that's ok because u can always fall back to square brackets
an we kinda do GC but not really and heck - what uses to take 5 lines
is now gonna take you 35.

That sounds like a blast to me.

A language that has had 1 major update in the last 25 years, compared
to a modern, well thought out language? Please.

-----------------------------
e-wayne <at> isit.gd
t-07525 424 882

MonoTouch mailing list
MonoTouch*******/mailman/listinfo/monotouch

This will become a circular argument very quickly. Semantics. I don't
need my compiler to wipe my nose for me. C# is a very nice language, but
I think you are over stretching the bounds slightly. I think every
developer that is used to a specific language and syntax will be able to
reel off a list of gripes about language X. It's not helpful. Coming
from a long history of Pascal, I initially found the lack of Sets and
enumerated array indexers in C# absolutely horrifying. I survived. You
will too.

I don't think we should dilute this post by going into a language flame-war
on features as it would be obviously futile especially in this mailing-list
we already know the opinions of where the language superiority lies.
I will say this, having developed with both languages (all my published apps
to this point have been done in obj-c), there are areas where C# is
infinitely more productive. e.g. Cutting up datasets with LINQ and generic
collections (which I routinely find myself doing) effectively requires no
thought in C# while very lacking in Obj-C.
Accessing web services are also a tedious endeavour with Obj-C especially in
this area, code-gen is not just important it is a recommended software
discipline to automate all the redundant boiler-plate code removing human
error and making re-factoring possible with evolving web services.

This is the problem I have with the current T.O.S it does nothing to promote
higher quality apps - in some cases it goes against standard practice to
actually promote poorly designed lower quality applications.
These rules are not based on merit as they don't target the end results they
target the means, with the main purpose of anti-competitively increasing the
development costs to support competing platforms.

Regards,
- Demis

:)

True. I'm just struggling with a very hard decision and I'm not helped
by the bitterness I feel related to how I got to this point. They
could have phased in this stuff, given us a fighting chance. But no.

-----------------------------
e-wayne <at> isit.gd
t-07525 424 882

My point too ;-)

Sure, I agree, It's a lot to do with of familiarity too.

This is also my problem with the clause. That and the implication that
building Objective-C frameworks on top of the published API is no longer
allowed. THAT is what I want clarified and what I really object to, but
is obviously not related to MT, so I will leave it at that.

Absolutism is the way of the Jobs. Always has been, sadly looks like it
always will be.

M

This move further proves that Apple does not believe its own developers can
improve their dev platform.  If you can't beat them just make it illegal for
them to exist.

Remember Apple's commercial from 1984?  Apple has become the very company
they tried to make us fear.


D

"Absolutism is the way of the Jobs."

I used to hold him in high regard, his relentlessness and attention to
detail has produced some amazing quality hardware and software where up
until now they have achieved their market dominance because they are the
best at what they do.

Unfortunately they have no restraints in abusing their new power to wipe out
ISV's without any regards of the consequences - I've peaked into his
dominated world view and I don't like it.
Everyone is too scared to say anything negative publicly in fear of the
consequences.

I no longer trust him with investment of my efforts and will be one of the
first to defect to Android as soon as it becomes a commercially viable
platform.
I just hope the other players in this market recognize that they are an
unstoppable force and unite in promoting an open platform like Android
before they become fragmented into irrelevance. Looks like Palm is already
looking to cash out.

Until then I'm going to explore HTML5 tech on the iPhone - unfortunately the
visible rendering I've seen in the demos does not inspire much confidence of
it on this platform.

- Demis

Ah, the 128K Mac. A design great that was crippled by Jobs (lack of RAM
to meet a lower price point - it barley ran most of the apps, no
expansion - sealed unit, no fan so that it was likely to overheat.)
playground from '85 till whenever he returned (the late 90's?) It has
slowly crept back though.

With all due respect, Android will never be a viable market when 57% of its applications are free.  There's a level of expectation in that community that just doesn't allow for much commercial success in my opinion.

Brent

That article makes a basic mistake on the grounds of backwards
compatibility.

Apple needs to ensure backwards compatibility for all the software on the
AppStore, or risk having applications stop working.   This needs to be done
regardless of the languages and tools used to develop the software.

In particular, if you use a third party library, let us say "CuteJsonParser"
and you break the OS compatibility, every application using CuteJsonParser
(and probably more) would be broken.

If they were to break compatibility due to a major cause (let us say,
"security hole" for the sake of the argument) it would be easier to get
large swats of applications fixed by having developers recompile their code
once with an updated tool, than having thousands of developers all audit
their code.   This is a classic one-to-many is better than a many-to-many
setups.

Miguel.

Hello,

With all due respect, that is FUD. Pure and simple. What you actually

Opinions aside, newer languages have evolved to eliminate a large class of
common programming mistakes.

As anyone that has written large systems in C, C++ or Objective-C there is a
whole class of programming errors that developers in these languages make
that just do not exist with managed languages: buffer overflows (the source
of most security exploits in the last few years), double-frees (leading to
corrupted heaps), reuse of freed buffers (leading to corrupted heaps), leaks
in manual GC (cycles in refcounted systems), mismatches in contracts vs
implementations (subtle differences in header files included), runtime
errors due to type mismatches that go from a crash (C/C++) to a runtime
exception (when you use NSObject of one type with another type, "invalid
selector").

Everyone that has used those languages has come to value fairly expensive
tools: Purify (2,830 list price for 12 months software rental), PC-Lint
(398) and most recently the open sourced Valgrind.   Sadly, none of those
run on the iPhone (although Valgrind runs to some extent on the iPhone
simulator, but requires you to be an advanced Unix hacker to get it to even
properly run).

There is another class of problems: memory leaks, but Apple provides a tool
that can help here (Instruments).   But every study on complexity agrees
that automatic memory management reduces both code complexity, code size and
surface area that developers have to deal with to write software with fewer
defects.

Garbage Collection plays two roles: the first is to free the developer from
bookkeeping, but the *most important* feature is that it enables the
type-safe system that eliminates that whole class of errors described
before.

If you have the budget to pay for senior developers, this is not a problem;
  If you have the budget to pay for double the programmers, this is not a
problem;  If you have the budget to pay for the extra time it will take to
build the software this is not a problem;  If you have the tolerance to ship
later, this is not a problem.

But not everyone can afford that, and that is why language design continues
to evolve and that is why languages like C# and Java continue to improve
year after year, because they help reduce defect rates, and increase
programmer productivity.

You can see it today with the web: first developers had to write C code to
write dynamic web pages, then we got CGIs, then we got scripting languages,
then we got Java, then .NET and the revolution of the web as we know it, the
revolution that made web application development pleasant was lead by a
scripting language that had all sort of dynamism: ruby on rails.

Use the right tool for the right job and all that.

But, this already happens. I know this from experience. Upgrading from
2.x to 3.x broke a number of my own apps because API's had been altered
in 2.0, old version deprecated and REMOVED in 3.1. Apple is NOT afraid
to do this.

Another less applicable example: on the 3G, memory is tight. I
frequently use one of those 3rd party "process killing" apps (Memory
Info IIRC) to get as much free RAM as I can before playing games like
Worms, Plants vs Zombies and Hockey Nations 2010. It is no longer
available in the AppStore, due to it using private API. It doesn't even
vaguely work in 4.0. Sure the app runs. It doesn't work though.
Something changed under the hood and this is obviously why Apple clamped
down on private API use recently. Yes, this is private API, and one
could argue that is a different case - except it isn't restricted to
private API, as noted above.

You can't make wide sweeping statements about Apple. It just doesn't
work like that in their ecosystem.

Coloquay irc no longer works on 4.0

-----------------------------
e-wayne <at> isit.gd
t-07525 424 882

MonoTouch mailing list
MonoTouch*******/mailman/listinfo/monotouch

You missed my point.

The article makes the claim that "Runtimes can break and all apps will be
broken".   Fixing apps that depend on the runtime is easy: you rebuild the
runtime, you rebuidl the apps.   Runtime fixing takes place once, and gets
every app fixed by rebuilding.

And all of this can be done before the SDK becomes public and the SDK goes
live.

One-to-many vs many-to-many.

Your other example is irrelevant, apps that use private apis, they deserve
to die (on iPhone and *every other* platform).

Granted. Without that app though, the 3G is pretty much unusable these
days. *shrugs*

Worth taking note of: An update[1] to a November 20th post regarding
PhoneGap and Apple's new developer agreement states:

[ Update:: April 13, 2010 ]

I have received word from Apple that the above is STILL true! If you were

Apps built with PhoneGap will continue to be reviewed based on their own

So enough with the crazy speculative rumour mill. Let’s get back to making

Of course, as per its description[2] PhoneGap isn't a development tool per
se, but it does allow developers access to the underlying Objective-C API
using Javascript which in and of itself seems to violate the terms of the
new developer agreement.  Whether any apps submitted to the AppStore that
use PhoneGap are approved or not is yet to be seen, but it does seem worth
contacting Apple for proper clarification.

[1]  http://blogs.nitobi.com/jesse/2009/11/20/phonegapp-store-app[..]
[2] via  http://www.nitobi.com/products/phonegap/  PhoneGap is described as:
Mobile app development made easy

Nitobi's PhoneGap is an open source solution designed to give web developers
JavaScript access to popular mobile device features, like the camera, GPS,
the accelerometer, local SQLite databases and more, without having to write
full applications.
How does it work?

The PhoneGap framework acts as a bridge between web applications and mobile
devices. It lets developers wrap web applications inside a native
application, making development easier for those who aren't familiar with
Objective-C and Cocoa.

--
/M:D

M. David Peterson
Co-Founder & Chief Architect, 3rd&Urban, LLC
Email: m.david*******
Office: (801) 924-8167
Mobile.SaltLakeCity: (801) 419-5975 Mobile.Seattle: (206) 999-0588 http://3rdandUrban.com  |  http://amp.fm  |  http://mdavidpeterson.com  | http://broadcast.oreilly.com/m-david-peterson/

I would rather code in C# then JavaScript.

--
Kind Regards,

Lennie De Villiers
Soliditech (Pty) Ltd
SOLID INFORMATION TECHNOLOGIES

23 Franklin Road, Cape Town, 7708
Telephone:  27 21 674 6662
Fax:  27 86 50 11 099
Email: lennie*******
Website:  http://www.soliditech.com
Disclaimer:  http://www.soliditech.com /disclaimer.html

Well technically Phone Gap just allows HTML/JS apps to be embedded inside a
native application, the T.O.S explicitly allows JavaScript to run inside the
WebKit Core.
The only issue I see is the 'callout' into native code which I'm not sure
violates any T.O.S itself unless it can be classified as a meta-framework.

Anyways its good it's being allowed, it means Apple is at least open to
allowing *different approaches*, which I will probably use if MT is denied.

- Demis

What gets me is how they have had comms with apple yet no one elase can?

-----------------------------
e-wayne <at> isit.gd
t-07525 424 882

Well technically Phone Gap just allows HTML/JS apps to be embedded inside a
native application, the T.O.S explicitly allows JavaScript to run inside the
WebKit Core.
The only issue I see is the 'callout' into native code which I'm not sure
violates any T.O.S itself unless it can be classified as a meta-framework.

Anyways its good it's being allowed, it means Apple is at least open to
allowing *different approaches*, which I will probably use if MT is denied.

- Demis

MonoTouch mailing list
MonoTouch*******/mailman/listinfo/monotouch

yeah - i tried that! never got a reply - i also tweeted Obama - same - they
must be busy or something ;)

haha

w://

The problem with MonoTouch is the 'Originally developed using...' (i.e. no
C#)
My suspicion is the lack of response is because a) they haven't made up
their minds - good; or b) they have and only want to announce 'positive
news' - bad.

- Demis