Apple contacted a(n unknown-to-me) number of iPhone web app developers
on Thursday, offering advice on how to make their apps work properly
on iPhone in time for launch Friday. (Let me say publicly: That
gesture was *greatly* appreciated!) I was contacted by a member of the
iPhone/Safari/WebKit team in order to improve the "iScopes" app I
created for Astrology.com:
(If you stop at just "/iphone", you'll get a landing page that's
missing an iPhone-specific optimization (namely, the viewport meta tag
we've all come to know and love), which is rather funny considering
the heading. :) That page should be updated "soon".)
I've been released from the Non-Disclosure Agreement covering the
conversation, so I'll share some of the things from it. Consider this
information second-hand and hardly definitive. I don't speak for
Apple, and it's entirely possible that I misinterpreted some things
that were said. (In particular, I mention a few times that my contact
didn't offer workarounds for this or that limitation. That doesn't
necessarily mean that there *aren't* decent workarounds, perhaps even
"easy" ones; my contact may simply be unaware of them or unwilling to
go into them or whatever.)
x iPhone Safari isn't the same as Safari 3.0. They
"forked" a while ago. If you don't have iPhone,
they recommend testing apps in Safari 2.x and
3.0 on your Mac (or, presumably, PC). On iPhone,
an app will tend to perform somewhere between
the two. (Note that iPhone-Safari has a great deal
more CSS3 support than Safari 2 (though not quite
as much as in Safari 3). So, your app might look
*terrible* in Safari 2 --mine does-- but still
render nicely in iPhone.)
x For animations, they recommend using 'setTimeout's
with wait parameter set to 0:
// set up animation global variables, etc.
setTimeout( "stepAnimation()", 0 );
// do something
if ( !finishedAnimating )
setTimeout( "stepAnimation()", 0 );
(Sample code mine. Typed on-the-fly. Ignore errors.)
The contact considers 'setTimeout's better than
'setInterval's, although that might just be his
personal preference. (Still, he recommended changing all
my 'setInterval's to 'setTimeout's during our debugging
Note that, on a Mac, animations set up this way will zip
along in a flash, making debugging tricky. However, on
iPhone, they're *much* slower.
x The first tip given was about that viewport meta tag
<meta name="viewport" content="width=320" />
My contact didn't say anything about scaling parameters,
however. (I didn't know about them at the time, so
didn't ask. Perhaps I should now. :)
x iPhone-Safari doesn't send any specific messages when
flipping to landscape mode.
Naturally, I lamented greatly about how my landscape-
specific stylesheet was going to go to waste, but the
response was basically, "Sorry about that". My contact
offered no real hope of a workaround, which is why I
was very pleasantly surprised by Christopher Allen's
recent viewport experiments that show there *are*
resize messages being sent eventually. And, as Joe Hewitt
has shown, one can do continuous polling to determine if
the screen dimensions have changed. These "hacks" may be
our only options at this point. (My conclusion, not
anything suggested by Apple.)
x Flick-scrolling. This is, as I surmised in a different
thread some time ago, a "meta" feature of Safari that
is meant *exclusively* as a way for the browser to move
the entire window up and down quickly. That's why the
title bar moves. So, the only way to flick-scroll through
a list is to display that entire list on a really tall
page. Flick-scrolling is not, therefore, for manipulating
scrolling divs *within* a web page. Again, I lamented that
I'd been *expecting* users to flick-scroll through items
in one of the "panels" of the iScopes web app, and again,
the response was "Sorry about that". No suggestion to use
iframes or other workarounds.
x Contrary to what we may have seen in Apple's promotional
videos, there's no way to hide the Safari location bar or
tool bar (yet). (I'd *swear* the guy said "yet" ... but
don't hold them to that.)
x There's apparently no way to suppress that "darkening"
effect when clicking on a div that takes a mouse event.
(Very unsightly when your buttons aren't rectangular
and/or don't extend to the boundaries of the clickable
div.) I was told that they'd "look into it", but don't
expect anything anytime soon.
x They're working to put together documentation and
guidelines and sample code (for "cool effects") for all
of us, but I was given no idea of the time frame on that.
I think that's all I have at this point. Feel free to ask for
clarification, although I don't know if I can offer any more clarity.
Our primary focus in the conversation was getting my *specific* app
working properly. Many of the things I list above came from tangential
comments related to what we were discussing. I didn't think it an
appropriate use of my contact's time to pump him for details on every
open question about iPhone web app development. (I certainly don't
want to wear out my welcome with Apple; as you might imagine, I value
"Day Late" Don
Day Late & Dollar Short Software
All I was told was about the viewport tag (it was funny because he
gave me the line and started off by saying "less than sign, meta,
space, ...., greater than sign", and he tried to tell me about the
Google Maps integration (which I already knew about from someone who
attended WWDC and contacted me), but he never really got through to me
on that since by the time he called for that, I was already waiting in
line for my iPhone.
P.S. Cute app, by the way...
I was not contacted by Apple, even though two of my apps (Digg and
Chat) got considerable press coverage, so they must have been aware of
them. I hope this is a sign that they will be releasing a native
iChat app in the near future and either deemed it unnecessary to get
my chat app working or didn't want to dodge my inevitable questions
about the need for my app.
On Jul 2, 2:05 am, DayLateDon <dayl...@gmail.com> wrote:
I gotta say though, if Apple wants to embrace the web development
community and web standards, they're certainly off to a HORRIBLE
start. All this NDA stuff is a bunch of nonsense. If they were
really serious about web apps being the primary way to develop third-
party apps for the iPhone, they should have publicly released
guidelines on how to develop for the iPhone on the day of Job's
Keynote. So now here we are days after the release of the iPhone and
still no public guidelines? ... and come to find out Apple is picking
and choosing which developers they give additional information to?
Memo to Apple: that's not the way the web standards community works.
We share information and we work from the same standards. We embrace
technologies that are freely accessible to everyone and we reject
technologies that are part of a walled garden, "it's who you know and
how much you're willing to pay", mentality.
I'm really hoping that these are just some initial missteps. But its
certainly not a good sign of where Apple is headed. Its in their best
interest to have the maximum number of developers interested in
developing for the iPhone. They'll make a hell of a lot more money
that way than they will by trying to sell more tickets to the WWDC
where they dole out secret information.
On Jul 1, 11:05 pm, DayLateDon <dayl...@gmail.com> wrote:
The remarkable thing about Safari on the iPhone is that it works as
well as it does. Which is really amazingly well. Let's not lose sight
of that as we focus on the imperfections.
I'm guessing WebKit is still the meat behind every Safari version, and
that when Safari 3 is GM (around when Leopard ships), iPhone will get
a software update. It doesn't make any sense for Apple to have two
different versions of the engine, rendering in different ways, while
still claiming they're the same app.
"Safari 3 Public Beta, now available for Mac and Windows, provides you
with the ideal environment for Safari on iPhone compatibility testing."