Thanks for your feedback. Certainly lots of issues that we can and do plan to address. On the tools side, as several people have mentioned below, we are releasing a new IDE this week called Titanium Studio. This release will address two critical areas that you identified in your post: debugging and overall tooling stability. The IDE itself is based on Aptana Studio, which has several years of solid development behind it. Sample projects, code completion, and other frequently-asked features will be included. Titanium Studio ships this week.
Certainly there are other areas in your post where we can improve. Know that we are making investments in all of the areas you describe and we certainly appreciate everyone's support as we grow the platform, the community, and the supporting infrastructure behind it.
I appreciate your comment, and it's great that you're reaching out to the developers using your platform. I'm excited to try out the debugging features of Titanium Studio, and hopefully it's more transparent in the steps it's taking to build an application as well.
Your second paragraph rings a bit hollow though. I'm sure you all are committed to growing the platform, I'm sure you're making investments. What software company isn't trying to move things forward? But as a user, I frankly don't care about how much better things will be. I just want to get things done, and the current state of your product makes that difficult. Worse than that, the current track-record of development (as witnessed by may comments here!) doesn't show a lot of progress.
I earnestly look forward to seeing improvements in the near future, as I have an application to deploy and support!
Well, we just released Titanium Studio... with debugging. How's that for moving things forward? And sample projects and code are included, with a ton of new features coming in the full release later this quarter.
We have about 2,500 apps being built per month now. This number is increasing by about 50% month over month. In total, we have over 15,000 apps in the various app stores. That puts us as #1 go-to mobile development platform behind Apple and Google. Seriously.
Obviously, we'd love it if everyone was successful, but we're 50 people and running flat out. And that last round of $9M in funding? It's gone to QA, to acquiring Aptana, to adding 5 engineers in the past 6 weeks on Android, to quadrupling the amount of content out there (have you checked out our latest guides? They're awesome! http://wiki.appcelerator.org/display/guides/Home). There's a ton in there... and most have been written by the community!
Look, I'm not saying that we're perfect. We have LOTS to do. But we're a platform company that's listening intensely to developer needs on a very frequent basis and making big investments in the areas that need the most help.
So, yeah, Q&A needs a forum. Our API needs more parity, we certainly need to be more responsive to the 100 or so questions coming at us every day. But c'mon, if you're going to build a real native app in no time, a platform that has 3,600 methods and processes in use by 130,000 active app developers must have something going for it don't you think? Try Wunderlist. Try GetGlue. Try ScoutMob. These are all top apps written on Titanium with small dev teams. None of these apps were built with a support subscription, btw. Stick with it and you'll see just how much can be done with the platform.
Give us another shot with Titanium Studio and the other cool stuff that comes out this quarter. We'd love to see you back as a Titanium fan...
Thanks for letting us know some of the backstory there.
It may be just me, but reading your comment makes me more worried about lack of focus there than less... It just seems very frenetic.
I've been developing on Titanium for several months now (as a paid subscriber) and more and more the decisions and priorities of the company really puzzle me. It seems like Appcelerator mostly ignores a shaky foundation while excitedly piling more 'features' on top of it and using tons of duct tape to try and keep it from collapsing before the money runs out.
The most compelling evidence for this is the pull requests being ignored for long periods of time. How can we be excited about a platform that is so slow to even accept help from the open source community to improve it? Meanwhile, I frequently get calls from Appcelerator trying to get me to buy in-person training and even a new 'certification' program. Really?! That's where your putting your resources rather than the actual platform supporting your 'platform'?
I really really want to like Titanium and be a fan, but right now it seems like asking me to please be a Microsoft fan. At this point I'd probably recommend MS over Ti. That's not a compliment :(
Please please please focus on your core experience. Ignoring it will drastically damage your reputation among hackers (as you can already see happening) - and hackers are the ones who decide which platforms to use (and which to abandon).
I would gladly pay several times more than I am now for an 'A' quality platform. Money is not an issue for many of us developers, but quality will be the deal killer here. I've many times wished that I could even pay a bounty to fix certain platform bugs.
I had a similar experience with the platform. I was very excited, browsed through the APIs to check the required features were there and jumped in. It then took ages to get the right versions of SDKs/XCode and Titanium installed, which also involved searching though forum posts and patching files. Finally I got the "Kitchen Sink" app working. All was good.
I started implementing my app and quickly became flummoxed by the difference between seemingly identical windows (it's all down to "execution contexts" explained here http://iamwil.posterous.com/when-it-comes-to-titaniuminclude... not in the Titanium Docs).
And now Apple have made their subscription functionality the only game in town and that module (StoreKit) will cost a hefty Appcelerator subscription ($2500/yr, IIRC)
Bah... I've abandoned my Appelerator prototype and I'm going to try out PhoneGap which looks like it's really improved in the past ~6 months
I agree, PhoneGap today looks much better than it did when I started this project on Titanium about 6 months ago. I definitely wish I'd gone that route in retrospect.
I created a iOS app in Titanium Mobile as well, and agree on your points. In addition:
- Multi platform support is very bad. A lot of functionality is working in a different way or not at all in Android and you'll have to find out most of this by trying.
- Stuff breaks with new versions of Appcelerator
- Due to the lack of feedback in the compilation process debugging some problems will take hours
- Creating a complex state-based navigation other then just a basic navigation controller is quite hard and bug-prone, a lot of it has to do with the sometimes very eager garbage collection (completely overlay a item with another, remove the overlay and the underlying element is gone, because it has been collected).
On the other side though:
- Development is a lot quicker (allthough you will lose time fixing stupid bugs).
- App works just like a native app and is quite fast
- A lot is possible, including custom fonts (using them in 3.1 causes a crash, so iOS 4 only, not documented though and caused crashes in the app on iOS3, so be careful, took me a while before I found this), the kitchen sink is a better resource as the docs.
For my next mobile app I think i'll use PhoneGap, since HTML is more portable. While I developed this app I had the constant fear that I would come across a bug that would stop me from finishing the product. It's a risky thing to work with, but you can get some great stuff out of it in no-time if you're lucky.
I don't disagree with him but I still think Appcelerator is worth it. Because as annoying as Appcelerator can be it's still quicker than writing your app twice and Apple's devotion to objective-C makes it very hard to carry over code from other platforms.
I would give two warnings though (which are supported by the author's piece)...
1. You need to make sure your use case is covered in the Kitchen Sink example. If you can't take those pieces and put together what you want to build than you shouldn't bother with Appcelerator (the documentation is pretty useless)
2. You need to buy support. The community is non-existent but the staff support is pretty good. A lot of times their advice boils down to "just ignore that error" but that's helpful with a lot of the errors generated.
Also note Appcelerator just bought Aptana, a company that makes development software. So clearly they realize there's a problem are are taking steps to fix it.
Edit: One last thing in their defense. Though they've been slower than I'm happy with in making their platform easier they have added a lot of new features. Things like Bump, bar code reading, credit card reader support and in-app purchases aren't available elsewhere (though these were just announced so I don't know how well they work yet)
I haven't bought support, so I can only speculate based on their community forum, and public bug tracker. With that out of the way, unless paid support gets custom code deployed to them fixing core platform problems, I don't see it as being a solution.
In it's current state I couldn't recommend Titanium to anyone. I hope it continues to improve, and get better, as both the idea and implementation have a ton of positives, it's just almost unusable right now for anything big enough to really see the benefits in the multi-platform support.
I'd be interested to know what you consider the core platform problems because I've never run into anything that couldn't be worked around.
Don't get me wrong. I sympathize. I lost several nights of sleep because I was so angry after a day of using Appcelerator that I literally couldn't calm myself down enough. There were days when I'd decided to not only stop using Appcelerator but to make it my life mission to tell other people to stay away from it.
But those days passed and eventually support (and a lot of manual error checking) got me through.
I think most of us here mean Titanium Mobile when we say just "Titanium." Their desktop platform seems to have received much less attention from them, and is of much more questionable benefit than the mobile one, which doesn't have many alternatives whereas on the desktop there's Qt and all sorts of other things available.
My biggest beefs are: the fact that the build system is a complete black box that fails without a good indicator of what it takes to fix it, and inconsistencies in how events are handled, 'swipe' and 'scroll' being prime examples of events that either don't work as expected, or work in unexpected ways.
Aptana makes Java based SDKs and Eclipse plugins. I don't understand how having a slow, bloated code editor as your recommended development environment is going to fix anything.
Sure you may get better debugging tools, but that doesn't change the fact that their API is still incomplete, buggy, poorly documented, and lacking support.
Appcelerator's problem is focus. Instead of making their API rock solid on core platforms and building from there, they shipped it half finished while they chase after the next shiny thing (Blackberry support! Card readers! Our own code editor!)
I completely agree with your last sentence. I don't begrudge them opportunities to monetize their platform, but I can't help but be frustrated at watching new functionality being added on top of piles of bugs.
Your mention of the bar code reader is a particular sore spot with me. They've been promising to release it since October of last year ("just wait until next month") and then when the finally released it a couple weeks ago it only supported QR Codes.
I'm current knee-deep in building a Titanium app for iPhone, and my experience has roughly matched tannerburson's, however, I have had far less difficulty with some aspects. For instance, I am using one line JavaScript IFs with no warnings.
The API docs are incredibly sparse, however, helpful enough for the nuts and bolts of dealing with our JSON API, storing to plist files and using the built-in HTTP client. I am currently wrestling with structuring our app such that it fits to one of the paradigms given in the Kitchen Sink; this has been incredible tough. As noted by others, sliding and scrolling behavior is erratic.
Our current iPhone interface is a fully manifested jQtouch web app, and I have pushed the performance of the app as far as possible. It isn't terribly slow, however, it one of the main bottlenecks users have in interacting with our service.
I originally set out wrapping our jQtouch app in PhoneGap - a simple task. However, given the way that PhoneGap works, the performance was no better than the current web app. I then completely rebuilt the app in jQuery Mobile (Alpha 3 at the time), loaded it into Phone Gap and discovered that the interactions and load time were slower than my original jQTouch app. This isn't to knock jQuery Mobile or PhoneGap; rather it is a reminder that for a full jQuery Mobile or jQTouch app you are looking at loading 140-200Kb of JavaScript every time you open the app. If Nitro ever comes to homescreen apps, this will be less of an issue.
The long and short of it is that while PhoneGap certainly gives you infinite flexibility in what the UI of your app can do, you have to be vigilant about keeping your load times down by minimizing frameworks. If you already have built an iPhone web app that meets your performance requirements, load it into PhoneGap.
Alternatively, if you want a fast, lightweight app with a UI that mirrors one of Titanium's demos given in their Kitchen Sink, then I believe that the struggle is worth it. All of my commentary is working under the assumption that you have no Objective-C experience.
I recommend downloading the app Wunderlist to get an idea of the extent to which one can customize a Titanium app.
This was about 5 months ago, so it's possible they drastically improved it in that time (although it doesn't sound like it). But I ran into the exact same issues.
Debugging was a pain because of you were writing JavaScript rather than Obj-C and the line or file on some errors were on were entirely unhelpful.
Performance (which you don't notice in the simulator) is poor. I was working with tables on iOS, even after cutting the app down to using 10 rows, people noticed a lot of lag on iPhone 4s (and it was unusable on a 3G or 3). This was with the only scroll events being a scroll position check suggested by the KitchenSink demo they provide.
Entirely possible this was something I missed, but while it says cross-platform, you don't really get cross-platform. The difference in UIs between Android and iOS means you're going to be writing quite a lot more code to actually get an app that works on both Android and iOS.
Colleagues of mine are paid users of Appcelerator's small business offering and have said the exact same thing: no community on the other side of the pay wall either, and little to no developer interaction.
Yeah, it's too bad. I know a guy on the development team, and I think they're doing a great job given the complexity of the task they've taken on, but I can't recommend it for anything other than prototypes or very simple applications.
Based on what little I've seen, this sounds accurate. Both Android and iOS have a large amount of features and controls that developers are used to having access to - distilling that down into a simple codebase can't be easy.
It will be interesting to see if any early adopters continue to support Appcelerator; I'd love to see what their product looks like in a year or two. At the moment, my work is a little too complicated and urgent to want to rewrite anything for an immature codebase.
I had a similar experience. I built a iPhone app using the Titanium platform, and decided against releasing it in favor of rebuilding it in Objective-C. I was able to work around the lack of correct documentation, platform inconsistencies, and software bugs for the most part, and was able to get the software to run consistently and reliably on my iPhone 4, but it would randomly crash on iPhone 3's, and iPod touches. The issues seemed to be related to memory management and/or threading. Ultimately, I felt that I would be spending just as much time fighting with the middleware as I would spend writing Objective-C library code, and I would actually be able to debug the library code.
I still value the work I did on the Titanium platform from a prototyping perspective. It did allow me to quickly try a number of things that didn't work, and come upon a workable design. If I could do it over again, I would still prototype with Titanium until I had a design, then port to Objective-C before I actually made things work in Titanium. You can get acceptable performance out of Titanium, if you have a knowledge of the way the underlying SDK works. For example, because I had implemented iPhone and iPad app's before with Objective-C I was able to write the code so that it conformed to the underlying sdk assumptions, in particular tableview code performance wasn't as much of a problem for me as it was for many others because I was aware of how the middleware was likely transforming the code, and was able to construct it to maximize cacheability. I suppose with some platform familiarity and a very simple app, Titanium could be workable.
The decision to port had a couple of other advantages, chiefly that it allowed access to some of the open source mobile plugins that are quite useful, like ShareKit and some of the Augmented Reality code, along with deeper integration and better performance. Switching to Core Data seemed to be reason enough to port.
In the long run, I hope that Apple sees that there is a demand to develop iOS apps in languages other than Objective-C. I would estimate 95% of the iOS code I have written has not been performance sensitive, but has been glue code tying chunks of Apple's SDK together or IO bound background networking code. Being able to use a less verbose language with an extensive standard library and strong C bridging like ruby would speed development without seriously harming performance since sensitive code could still be written in Objective-C.
This was my experience as well actually. I looked at phonegap appcelarator and rhomobile for a while but it seemed that there was such a steep learning curve that you could just build things in the native platforms and have full access to the everything rather then having quasi access via webkit.
All three really were a letdown frankly. Right now im learning Jquery Mobile which oddly enough is kind of cool. Its got a decent community behind it. ANd its jquery so its somewhat more generic.
- Android is Java, iOS is Objc + (cocoa nightmare), Windows Mobile is silverlight (If i'm not wrong)
- iOS (cocoa) is a pain to learn and develop something useful out of it, plus you have to pay dev licenses to apple anually,etc..
- Android store doesn't have the projection Apple store has.
- Native wrappers (titanium, phonegap,etc..) are buggy, lack user support, poor documentation, limited.
So, choose your poison.
What's the solution ?
It's freaking insane if you want to have an app for every mobile OS out there at the moment, you need to have at least 2 different teams maintaing code. It's just stupid.
Wrappers are not the way to go fore sure, I think vendors should start considering using standard tools like Javascript, or more easy languages like ruby,python, at least for creating more simple tools, that don't require heavy graphic engine and stuff.
At least this would help companies reduce their efforts on having teams different for each OS.
The concept of Outlet was very strange to understand at first, I never knew what should I connect to what (iboutlet, ibactions), then, the cocoa classes methods are big and enigmatic sometimes. I also found that creating a simple tableview with simple content is frustrating, because you have to link so many different steps, you have to create an object for table view, create delegated functions for counting and adding items, create a mutablearray, link it to the tableview, reload it everytime you need to display...and I'm not talking about adding images and stuff.
I'm pretty noob at cocoa, but it's a very hard learning curve because Objc and cocoa have so many specific standards that are strange if you came from other languages.
Interesting, I experienced similar frustrations starting out with rhomobile and was hoping the grass was greener on the other side.
My ultimate complaint with rhomobile is that the "native" apps are running in the web browser. I plan go into further detail in an upcoming blog post / presentation.
We used it to make a simple android app in the last month. It worked and I sure liked writing the app in JavaScript vs Java but we ran into huge issues with Titanium caching resources during the build process that were supposed have be removed or updated and leaving things behind that we then had to track down and manually remove. It basically just takes whatever is in the build directory and tries to package it with little validation for correctness. My suggestion to people using it is to sanity check the code it generates in eclipse or xcode as part of your dev process.
You need to clean your build directory whenever you change resources (i.e. add new images, delete old images). It makes the build take a bit longer but you'll have no issues. So i.e. just delete the contents of the Resources/build/iphone directory and then rebuild the app from Titanium.
I've used the android API 2x. I think it's quite rough to get Titanium installed, it's easy to misconfigure, and it's not a huge pile of time saved over just writing the logic twice. Just give up if you think you have to instruct a 3rd party on how to configure android + titanium on mac. It's a beast.
It feels like there isn't anyone there on the forums. I'm sure as hell not going to pay 2k+ a year to experiment further when the documentation is shoddy (it rarely explains what things do, I had to read source to get doc on the video player).
And the dashboard project doohicky is stupid as hell. Just make some command line tools already, or really really commit to a GUI that works well and supports things like rename. I shouldn't have 4 projects named the same thing because I didn't open an XML file myself and edit it.
If I really need crossplatform whatsits, I'm thinking flashbuilder or that ilk at this point. Titanium did not impress.
Wow, thanks for this write up, I had been considering trying titanium after an unpleasant experience with phonegap.
I went with phonegap for a project and hammered out my application quickly but then spent hours trying to optimize enough that it would run at a reasonable speed. I ended up re-writing as a native app but at least now I know.
So glad to see more people pointing this out. Titanium sounds like a great idea and they market it well, but when you look closer you quickly discover that it just fails to deliver. Sadly they seem too focused on spending VC cash on adding bells in whistles when their core functionality still doesn't work. Here are a few examples.
Running their sample app. This is the first thing every developer does, so you'd think they'd have nailed this much, right? Sadly, no. Check out all the forums posts about people struggling to get KitchenSink running:
Some of that is the complexity of getting the right 3rd party developer tools installed. But often projects will randomly stop compiling. Instead of fixing the underlying problem, this is their workaround (it's not just KitchenSink, it happens to your projects too):
They don't seem to have anyone who monitors their forums. When core functionality breaks and people report it, nothing gets done about it for months, even when the fix is as simple as whitespace. This was reported in Oct, and a pull request was submitted in Jan.
Open source means the community should be able to pitch in, but there are 16 open pull requests from the last 2 months, none closed or even commented on:
New features are rolled out with sparse documentation and then abandoned. Need to style a bunch of views, try JSS - except it's not documented in detail anywhere. But maybe they dropped JSS and are working on Helium?
Or not. Helium hasn't been updated in months and still isn't documented anywhere on the Appcelerator site. So who knows.
There are many other issues, of course. Ultimately you end up having 3 options: (1) pay them a bunch of money for support, (2) spend more time fixing their software then working on your own code, or (3) just writing native apps for the various platforms (or native web wrappers with HTML core).
I wouldn't mind paying for support if the product worked great, but paying to get support for something that's broken to begin with is frustrating. It's ultimately easier to just find alternative technologies.
Forgot one other big issue that no one seems aware of: Appcelerator tracks your development with their tools. Titanium Developer transmits analytics data every time you create/import/edit/delete/compile/test/install/distribute a Titanium project on your system.
To see the specific calls, just download titanium_developer and grep for Titanium.Analytics.featureEvent. If you do use Titanium and want to disable this, you should build a new version of Developer after adding the following line to tiapp.xml:
<analytics>false</analytics>
One last note: I don't make these points just to be mean-spirited. Appcelerator clearly has some talented programmers and great technology. But silent tracking isn't okay, and clearly someone at top needs to help them focus the talent they have.
Agreed. Seems like they are wasting away what once had great potential. All my bug reports (3 over the past two years) still stand unanswered and unacknowledged.
The API is broken in many ways. Documented features just refuse to work, and forum and bug posts go unanswered. I assume that paying customers have a better experience, but if they could be a little more responsive and helpful to prospective customers like me, I'm willing to bet they'd have a lot more paying customers.
I have been using <a href="http://the-m-project.net/>The M Project</a> for several months while building a web-only mobile app, currently in private beta and so domain-specific as to be useless to the general population. The framework builds on best-of-breed frameworks node.js and jquery mobile. Javascript ftw! The core developers hang out in IRC, or at least jump on when someone pops up with a question.
Turns out, they also have phonegap support, so I <em>could</em> deliver an app, but that sounds like more of a headache than its worth.
Lots of projects want to simplify the app development process, and there are even more startups working on automating the process. Ultimately it's fine for prototyping, but not much else. Performance becomes an issue and you rapidly hit it wall with anything but native apps.
It's good to get your feet wet and get excited about the platform, regardless of it being Android or iOS, but at some point you need to just bite the bullet and pick up a good book and start working.
I'm looking forward to the inevitable follow up post on the author's experience with Phone Gap... Has anyone used Phone Gap before and wants to share their thoughts?
We moved to Titanium from PhoneGap around 5 months ago - PhoneGap was just too slow for many options and did not support the low level audio functionality we needed. It may be better now though, but we haven't looked. Titanium has actually worked really well for us so I'm a bit surprised by so many developers having issues on here. Our app is coming out in about a month and is fairly large, with a custom UI:
There are an increasing class of mobile application that don't need native support at all - they just want to have platform-conforming UI. jQuery mobile, JQTouch, and Sencha Touch are examples of these platforms that require only HTML + JavaScript.
I've been using Titanium for 2 months now while developing a prototype version of our iPhone application (Android later), and while I share the author's sentiments on a number of issues, I'm fairly pleased with the results so far. I'm not an Objective-C guy in the least, but am reasonably good with JS, so it's a great way to go native.
That said, some comments:
- JS Warnings. It's true that one-line ifs, property existence checks, function closure suggestions, etc. can get a little annoying. My solution is to write JS which is 100% JSLint compatible, which is fair IMO.
- Titanium Warnings. These get annoying. I get dozens of "[object TiUIView] has an auto height value of 0, meaning this view may not be visible" warnings which are completely useless and don't identify the offending View for me to fix. Also, I get about a dozen errors like "<Error>: CGContextDrawImage: invalid context 0x0" which give me no indication which is the offending image. Etc.
- Performance. While native, our application runs a little sluggish and certain views are choppy when scrolling, and some style properties have bizarre rendering behaviour (layout: 'horizontal', width / height: 'auto', etc)
- Minor Revisions. The author is right, some minor revisions introduce pretty bad issues. 1.6.0 introduced some very noticeable performance degradations in TableViews, so we're still on 1.5.1 for now.
- Documentation needs work. The API reference is lacking any mention of certain parameters, which is frustrating. The wiki has more detailed information and has essential reads to understand things like TableViews, but I didn't find this resource for several weeks into my project. Many undocumented side-effects exist, like quirky behaviour on horizontal layouts, etc. Here's an example of the kind of confusion which results: https://appcelerator.lighthouseapp.com/projects/32238/ticket... The "headerPullView" feature for pull-to-refresh is currently undocumented magic.
- Barcode support is disappointing. Titanium+ introduced Barcode support, but does not support the usual 1D barcode. The additional libraries that exist (TiBar, zbar, etc.) are very difficult to compile in without XCode hackery, and sometimes don't work on the devices themselves, making debugging very difficult.
- Bugs in XHR with Content-Type and passing Arrays, requiring workarounds when integrating with Rails. Arrays get sent as "( key1: value1\n key2: value2\n)\n" .. seriously :)
- Titanium Developer required me to click "Launch" to start the application until I read Gene Tsai's comment on the original article which gives you command-line aliases to start your application. Awesome tip :)
At the end of the day, Titanium Mobile is a great solution, but be prepared to be patient while the platform matures, and to get creative in architecting alternate solutions when your initial approach doesn't work. I'm confident the wrinkles I point out above will be ironed out in time.
> Bugs in XHR with Content-Type and passing Arrays, requiring workarounds when integrating with Rails. Arrays get sent as "( key1: value1\n key2: value2\n)\n"
Can you elaborate on this? What is the Content-Type bug? What do you mean by "passing Arrays" -- how are you serializing?
PhoneGap and MoSync are the ones to try out for cross platform development, but honestly, it's probably better to design the app in such a way that porting it becomes as easy as possible.
"It’s only syntax/static checking is done via JSLint with a pretty arcane set of rules. Want to write one line if statements? That’s a warning. A for loop without checking for property existence? That’s a warning."
The JSLint step is optional. I build my Titanium projects via the commandline (I don't use the IDE thing at all) which bypasses JSLint. I use the more reasonable JSHint as integrated into vim, not as part of the build.
There's a difference between reading it and accepting it. More and more people are moving away from JSLint because of the Cry Wolf syndrome - real errors hidden in a sea of warnings based only on the "opinion" that they tend to be harmful coding style.
Certainly there are other areas in your post where we can improve. Know that we are making investments in all of the areas you describe and we certainly appreciate everyone's support as we grow the platform, the community, and the supporting infrastructure behind it.
Thanks again for your feedback
Best Regards,
Scott Schwarzhoff VP, Developer Relations