Jeff's keynote for TiConf Baltimore on June 28, 2013 in Baltimore, MD, USA.

1. TiConf.us
Titanium User Conference
June 27th, 2013
Tremont Hotel
Baltimore, MD USA
h"p://www.flickr.com/photos/ktylerconk/3181331268/

3. Fundamental Shifts

4. Mobile is disrupting everything
Huge opportunity & massive disruption
Mobile is redefining speed
Rate of change and disruption is unprecedented
The User is King
Users are the driving force behind the mobile revolution

5. Mobile Requires
a Fundamentally
Different Approach

9. 30,000,000
New Users of Titanium apps in the past quarter

10. iOS7 Update

11. Yeah!
:<
• We
all
get
to
change
our
apps,
all
over
again!
• Great
thing
for
Titanium
developers
(sort
of)
• Lots
of
interesKng
capabiliKes
– Background
processing
– Auto
layout
– Fullscreen

12. When?
• We
are
in
progress
on
it
now:
– Complete
regression
under
way
– Early
Apple
beta(s),
tools
pre"y
buggy
–
trying
to
understand
their
stabilizaKon
efforts
– First
priority
is
making
sure
current
API
and
Apps
works
• We
will
make
a
release
available
as
soon
as
we
can
–
assuming
Apple
gives
us
all
Kme
• iOS5
support
will
be
deprecated
with
release

13. Ti.Current

14. Recent
updates
–
3.1.1
• Official
Tizen
support
• BB10
Beta
• Google
Maps
v2
• Android
2.3.3
• 3.1.2
targeted
for
August

15. Ti 3.2

16. 3.2
Release
• EsKmated
availability:
Fall
(or
as
soon
as
iOS7)
• Major
impacts:
– Android
animaKon
improvements
– Improvements
around
Studio
Experience
– Expanded
CLI
capabiliKes
– iOS7
• Win8
in
progress
–
but
will
be
on
Ti.next

17. Big
items
we’re
focused
on
• Developer
ProducKvity
– Speed
of
development
(such
as
Alloy,
ACS)
– Speed
of
app
execuKon
– Improved
tool
chain,
flexibility
– Improved
Studio
experience
– Development
workflow

18. Cloud Update

19. ACS
+
Node.ACS
Success
• Massive
adopKon
happening
–
especially
by
big
companies.
– Approaching
billion
API
calls
– One
app
recently
did
2M+
API
calls
in
~30M
– Autoscaling
to
~3,500+
virtual
servers
• Big
capabiliKes
coming:
– SynchronizaKon
– More
enterprise
data
connectors
– Monitoring
/
management

20. The Appcelerator Platform
The only platform build for a mobile first world

22. Warning:
This
is
not
free
and
can
be
quite
expensive

23. Dashboard
DEVELOPMENT PRODUCTION
Users
Cloud Test Performance Analytics
Cloud Foundation
PRODUCT
MANAGER
DEV MANAGER QA MANAGER EXECUTIVE
APP
App Studio
Appcelerator Platform
DESIGNER DEVELOPER QA ENGINEER
DEVELOPER

25. Company Confidential

26. Company Confidential

27. Ti.Next
Company Confidential

28. Warning!
Disclaimer!
100%
of
the
informaKon
about
Ti.Next
is
likely
to
change
and
will
change.
It’s
sKll
a
lab
experiment
today.

29. How Titanium feels as an
App developer?

30. How Titanium feels as an
App developer?

31. How Titanium feels as a core
platform developer?

32. How Titanium feels if you’re
Jeff Haynie?

33. Ti.Next
• Next
generaKon
architecture
for
Titanium
– Leverage
over
4
years
of
learning
– Complete
re-­‐write
of
core
engine
– Ti
API
compaKble
(for
the
most
part)
– One
JS
engine
and
core
runKme
to
rule
them
all

34. Ti.Next
Goals
• Massive
performance
gains
– Reduce
footprint
in
terms
on
physical
size
of
binary
and
in-­‐memory
footprint
– Reduce
garbage
collecKon
overhead
to
minimal
– Simplify
threading
model
and
context
switching
– Increase
per
operaKon
performance
by
several
orders
of
magnitude:
~20+ms/op
-­‐>
~100+μs/op
– Move
from
naKve
language
to
ASM
generated
code
(ObjC-­‐>ASM
via
libffi)
– Faster
than
naKve
code
(in
most
situaKons)

35. Ti.Next
Goals
• Massive
maintenance
improvements
– Today:
• separate
teams
per
plamorm
+
core
runKme
team.
Many
different
skills
sets
required.
• TesKng
is
very
hard,
laborious,
error
prone.
• Linear
increase
in
cost
for
each
new
plamorm,
version
combinaKon
– Tomorrow:
• One
main
skillset:
JavaScript
• Be"er
ability
to
reduce
footprint
in
core
runKme
which
will
offer
ease
of
maintenance
and
upkeep,
easier
to
test
• Adding
new
plamorms,
features,
version
-­‐
much
faster,
easier

36. Ti.Next
• Extensibility
– Today:
offers
same
challenges.
Each
module
requires
naKve
language
skills
and
complexity.
– Tomorrow:
leverage
same
JS
API
to
create
cross-­‐
plamorm
modules
– Impact:
Module
API
will
change
dramaKcally,
require
new
modules.
Trying
to
find
a
way
to
have
some
level
of
module
API
for
portability
–
but
will
likely
only
work
in
small
%
of
modules.

37. Ti.Next
• Tooling
– Unique
tooling
per
plamorm
-­‐>
one
set
of
tooling
for
all
plamorms.
Invest
our
Kme
in
new
capabiliKes
vs.
maintaining
mulKple
integraKons
– Much
faster
build
Kmes
and
packaging.
– Increased
deployment
and
authoring
opKons

38. Quick
Demo?

39. Ti.When?
• No
idea
at
this
moment
J
– Likely
will
be
called
Ti
4.0
– As
usual,
release
oqen,
release
early
–
and
transparently.
– Want
to
have
first
set
of
developer
builds
available
soon
to
GitHub
repo
–
possibly
in
the
next
45-­‐60
days.
– ProducKon
builds
are
a
ways
away

40. Ti.Next
Approach
• StarKng
with
iOS,
Android
and
Win8
as
reference
architecture.
• Core
runKme
is
based
on
JavaScriptCore
(VM
part
of
WebKit).
– Leverage
new
iOS7
ObjecKve-­‐C
Framework
– Ported
new
ObjecKve-­‐C
APIs
to
C#,
Java
– Built
gyp-­‐based
build
tools
for
Win,
Android

41. Ti.Next
Architecture
• Small
footprint
“core
runKme”
based
on
JavaScriptCore
and
libffi
– <5,000
LOC
(vs.
100K+)
– Micro-­‐kernel
design
– Heavily
opKmized
for
performance,
memory
footprint
– Very
stable,
won’t
change
oqen
– Exposes
2
APIs:
• Core
RunKme
API
same
for
plamorms,
very
few
methods
• Core
Plamorm
API
different
for
each
plamorm
based
on
underlying
plamorm
API
(Cocoa,
Android,
Win8)
• Same
design
pa"erns
and
idioms

42. Ti.Next
Architecture
• Titanium
APIs
all
implemented
in
JavaScript
• Compiler
at
opKmizaKon
phase
will
convert
plamorm
APIs
into
naKve
code
(ASM)
• New
plamorm
APIs
can
be
accessed
without
upgrade
to
new
APIs
(before
Ti
API
work).
• Similar
to
how
node.js
is
built
(from
an
API
standpoint)
• During
development
phase,
no
(naKve)
compiler
required

44. THANK YOU
@jhaynie