[This episode is sponsored by Hired.com. Every week on Hired, they run an auction where over a thousand tech companies in San Francisco, New York and L.A. bid on iOS developers, providing them with salary and equity upfront. The average iOS developer gets an average of 5-15 introductory offers and an average salary offer of $130,000/year. Users can either accept an offer and go right into interviewing with a company or deny them without any continuing obligations. It’s totally free for users, and when you're hired they also give you a $2,000 signing bonus as a thank you for using them. But if you use the iPhreaks link, you’ll get a $4,000 bonus instead. Finally, if you're not looking for a job but know someone who is, you can refer them on Hired and get a $1,337 bonus as thanks after the job. Go sign up at Hired.com/iphreaks]
CHUCK:
Hey everybody and welcome to episode 128 of the iPhreaks Show. This week on our panel we have me. I’m Charles Max Wood from Devchat.tv. We also have a special guest and that’s Cesare Rocchi. You want to introduce yourself really quick?
CESARE:
Yeah, sure. My name is Cesare. I’m a user experience designer and developer, proud member of the Ray Wenderlich team that you had a few episodes back as far as I can remember. I’ve been an iOS developer since 2007 so I played illegally with the first iPhone 2G. Before that, I was a web developer and now I’m going back to my roots. So I didn’t leave native iOS development but I’m going back and trying to work again also on web technologies.
For example, in the moment I’m working on a product which is a service called Podrover which automatically collects podcast reviews and yes, a little bit probably also on iPhone applications.
CHUCK:
Awesome. So we are talking about web technology today specifically JavaScript Core.
I’m curious – why should iOS developers care about JavaScript Core?
CESARE:
Okay, shortest answer – they shouldn’t [laughter].
CHUCK:
Nice.
CESARE:
But we wouldn’t have an episode if I stopped there.
The point is, especially in iOS – well JavaScriptCore, first of all, has been available on the Mac since version 10.2 – I don’t remember the code name for that; some wild animal – jungle animal. It’s been around for quite a while but only last year with iOS 8, we saw JavaScriptCore – sorry, iOS 7 – we saw JavaScriptCore released and included in iOS 7. And to be fair, I would say it was pretty much ignored at that time. So it was not a cool topic to speak about at conferences and honestly, I met vey few people that used that.
But last year with the release of iOS 8, we saw a huge improvement on web technologies in iOS and specifically, talking about the WKWebView which is a totally new component that substitutes the good old UIWebView.
So I did some connecting the dots and that is based on JavaScriptCore. So of course I realized this and I was investigating a bit; WebKit.org – that’s the engine behind Safari and that’s open source. And so they published very detailed blog post about all the technologies that are part of WebKit and there has been a lot of work in trying to optimize the execution of JavaScript code within Safari. That’s why I connected all the dots so they had to release a JavaScriptCore coding called [inaudible] on iOS to enable the big release of WKWebView framework in iOS 8 and there’s a lot of optimization there especially when it comes to executing JavaScript functions within the virtual machine that comes in Safari.
CHUCK:
So with the WKWebView my understanding is that you can then have part of your interface built with web technology instead of with traditional iOS views and you can get some functionality that way that is shared between the web application and the iOS application or maybe it’s just easier to visualize or easier to put together with the web stuff.
CESARE:
So that was possible also before. You can create a simple or even complicated web page and load it using UIWebView. The great news with WKWebKit is the fact that you can have a dialogue between JavaScript code and native code. And when I say native, I mean both Objective-C and Swift so that’s the great news.
A pretty classic example of the functionalities of the WKWebKit is a demo in which you create your WKWebView and you iOS application or even your Mac application and you can inject some code in the HTML. That code can be – first of all, you can to decide when to inject it so at the beginning or when the pages load it and so on and so forth. That code can be CSS and of course, JavaScript.
So I have a presentation that I usually do at conferences about this and my demo essentially is extracting relevant information from the conference web page and displaying it in a native application. So essentially, I am using a web page as a CMS.
Of course, this is not probably how you want to build your applications day to day. You’ll probably have a JSON API, good documentation and stuff like that but just to show the power of this new component. And the fact that you can pretty much easily establish a connection between what just a few years back was thought impossible, so the dialogue between JavaScript which is a garbage collected language and Objective-C or Swift which is native Arc-based and so on and so forth.
CHUCK:
I have to wonder a little bit, you probably have web assets that you will hold in your native app for your web views versus web assets that maybe hold down from the web server. Is there a difference between the two? Do you think about those differently? And what are the trade-offs between having them local versus having them on the web?
CESARE:
Well, if you have them on the web, of course they’re much easier to update. So you screw up something and you just need to update an asset on a web server. Pay attention to caching because Safari and the web view are pretty heavy on that but you can easily fix it without releasing a new version of your application. But the assets can essentially be the same. If you can afford a CDN for example, there are dynamic CDNs nowadays that you load a big image through GET parameters, you can get a scaled-down version of the same image and of course you should put those values in the get call according to the device that is loading the image.
But I suspect, maybe I’m wrong, that you were headed in a very specific direction which is can I load JavaScript code from a web server.
Yes, versus can I load JavaScript code from my application and just bundle it in the assets that are available in that application and then install it on their phone.
CESARE:
Right, so if you have some JavaScript code bundled with in your application, you can load it from the bundle much like you load story boards and stuff like that and it's fine. You're safe but nobody will reject your application during the review.
If you load some JavaScript code from a remote position, from a remote server then I don't know. You probably could get away with it with the first version, maybe nobody will notice but I’m sure the clause and the review guidelines in which you cannot download code to be executed on iOS or the Mac is still there, I’m pretty sure. We might debate this but JavaScript is code.
CHUCK:
Yes.
CESARE:
So I’m not sure – I’m sure that technically you can. I'm not sure you can get approved easily on the App Store.
CHUCK:
Okay. I do know – okay let me back up. So I have been told by the Ionic framework team which is a team that puts together a framework that’s built on Cordova – we can talk about Cordova in a
minute. I'm pretty sure that it just works off of a full screen WKWebView. But anyway, what they said was that Apple has actually come out and said that you can dynamically update web assets in your application. So I don't know if that means that you can actually load JavaScript directly off of your web server but it sounds like what you can do is you can actually update those web assets on the device and then run them on the device.
CESARE:
Okay. This I'm not familiar with but I think there’s an important distinction to be made.
CHUCK:
Okay.
CESARE:
So you have mentioned that, of course, Ionic and many other frameworks are based on a web view. So if your application is essentially a web view, you can load all the JavaScript code you want because Apple designed WKWebView so they know they are the gatekeepers.
CHUCK:
Right.
CESARE:
It’s a sandbox, essentially, to safe environment. Whereas you could, and we didn’t talk about this, you could in native code create a context. There's a class called JSContext which for developers is essentially is window. And you create this class and it's much like you instantiate an invisible web view. So you have this sandbox in which you can inject JavaScript code. And I'm not so sure that the code that you can inject in there and which gets executed natively can come from a server or from a mobile application.
Okay. I think this is more of a ‘buyer beware, go look this up yourself and understand what the limitations are' but it is definitely an interesting area that you have to be aware of as you use this especially as you use apps that are using both iOS views and a WKWebView to display different parts of the data.
CESARE:
Right. Apple has been very careful in designing this because we've been locked down for six years. So for six years on iOS we had this UI – this dumb down version of UIWebView and the only method available – relevant method available was evaluate JavaScript from string essentially. But there was no way to send out call backs and stuff like that.
But it’s been a progression so my theory – my suspicion, pretty well funded I would say is that we needed XPC on iOS for this to happen.
So XPC, if you’re not familiar with that it’s interprocess communication, so it’s a foundation thing element that allows to exchange data between native processes on a platform. And XPC was not available on iOS for a long time whereas it was on the Mac. So XPC, in my opinion is the thing that enabled this native to web and back communication. That and the super smart optimization and the execution of the JavaScript.
There’s an article - I think Ribbon and Spring 2014, so more than a year ago about the optimization implemented in the virtual machine that is embedded in WebKit. It's three tiered; the first year was just an interpreter but as soon as it detects that some JavaScript function gets executed pretty often, it gets to the second tier which exploits just in time for optimization. And then the third tier which again is a form of just-in-time optimization but based on the flow of data within the JavaScript execution. And then the fourth one that they added which brings 40x optimization and execution time is rooted in LLVM which essentially, we are touching the bone of the [inaudible] system – the layer outside of the kernel, I would say, and all of that is just for JavaScript.
So this also tells that Apple is invested in this language. For example, not to mention that now you can do automation on the Mac using JavaScript. Maybe you've heard of AppleScript so you can script different behaviors for different applications. So now the same AppleScript can be read in in JavaScript.
As much as I – as JavaScript is not a love at first sight proven language and it's pretty much everywhere and probably it will be even more.
CHUCK:
So you can do the same things on MacOS that you could do in iOS with JavaScriptCore and these web views?
CESARE:
Yes, the framework is the same. There are few very small differences that I do not remember of but they are mentioned in the presentation about WKWebKit last year at WWDC, so 2014. But yeah, the behavior of WKWebView is essentially the same of all platforms.
CHUCK:
And I'm assuming that that's then the background for something like Electron. Have you seen Electron?
CESARE:
I'm not familiar with Electron.
It's very similar in idea to Cordova except it's for desktop. It’s written by GitHub and essentially you put desktop apps with web technologies.
CESARE:
I'm sure that's React by Facebook, heavily exploits JavaScriptCore.
The whole React is essentially writing JavaScript to generate some native view and without JavaScriptCore, essentially JavaScript and Objective-C cannot talk to each other. And the smart move in that case is also to do a lot of processing not on the main threat, so offloading to some other secondary that via execution of many JavaScript functions because they’re blocking essentially.
I’m not sure about Electron but I’m sure that there are other –.
CHUCK:
It says it runs on Node.js and Chromium so it's not quite the same.
CESARE:
Right, I was about to mention that. I’m familiar with a few projects like this that keep the core in JavaScript and on top of that build different native UIs according to the platform.
You could have the same core authentication with the server, fetch recent messages and stuff like that in JavaScript. Then on top of that you build your Cocoa UI on the Mac and the Metro UI on the windows and so on and so forth.
CHUCK:
I think that’s really interesting. Can you do the same kind of thing on iOS then where you have essentially your logic for talking to your server written in JavaScript and then your interface all done with Cocoa?
CESARE:
I’m not familiar with any project like that. I think you can but –.
CHUCK:
Will it involve one of these WKWebViews hidden somewhere on the screen?
CESARE:
No. I think what happens especially in the case of desktop applications, what happens is that day keep a Node.js server running on the desktop, whereas you cannot keep one running forever on any mobile device because the watch dog is going to kill it after 10 minutes or so.
So technically yes, you can implement the same architecture but you probably might need some refresh logic which is a bit more complicated than on a desktop platform.
CHUCK:
Sounds really good. One other thing that I was wondering about, it sounded like you could add this WKWebViews in different places on an otherwise Cocoa view application to display information or to fulfil some function.
And what I’m curious about is how do you make the two look like they belong together?
CESARE:
This is not an easy one because as much as you put blood and sweat and sleepless nights into this, you will probably end up with a result that does not feel native. And there are a great applications based on web technologies. So the Slack application for example, is responsive, is quick. I never experienced a problem with that but it doesn’t feel native, even the iTunes Store or the Mac App Store. And if you take a close look, you can spot it’s not a truly native application.
Even if the loading time is short and the animations are snappy and so on, I think we people involved in this field can notice that especially designers. I wouldn’t say non-tech savvy people notice that so they probably are happy with that.
CHUCK:
Now that’s really interesting because I knew that, for example iTunes on your Mac desktop, all of the information that it loads in there, that's all web technology.
I didn’t know that the App Store app on my iPhone also ran off of the web technology. I assumed it was all native.
CESARE:
Yeah, so I know that because I talk to people and also because sometimes you can experience some error in the CSS. But yeah, it’s snappy and of course if you want, I said something wrong in that. I said JavaScriptCore was not available on iOS for a long time. It probably was but it was made private because Apple, to implement something like the iTunes Store on an iPhone needs JavaScriptCore or something like that, otherwise you cannot implement such a seamless experience. You need JavaScript to talk to Objective-C or some dynamic library compile written in C++ and on a [inaudible] architecture. I mean they have to talk to each other somehow.
CHUCK:
Yeah, that makes a lot of sense. And it's also a lot like Apple where you see them basically implement some API that they've used for a long, long time. Think about the Apple Watch when it came out – for a long time, you really couldn’t do a whole lot with building your own WatchKit apps. And then they finally came out and said, “Okay, here's WatchKit and here's the next version of WatchKit,” but it was after they've banged on it and fiddled with it for a while and they don’t mind having to use the internals to make stuff work as they figured out the user experience for developers when it comes down to actually building stuff out. And we've seen them do this with other kinds of other libraries where it was, “Look, this previously wasn't available but now we’re comfortable with everybody using it so here you go.
CESARE:
Right. Yeah, and I've mentioned XPC. XPC again it's not available for third party developers on iOS. It's in there somewhere but you cannot use it and if you're going to use it, you're probably going to be rejected.
But going back to the iTunes Store example, I don’t know but I'm willing to take some chance and bet on the fact that the check out process is built in JavaScript. Because you keep all the logic in one place and if something was wrong, you'll know how to look and fix.
So you have at least three clients in this case because you have the iTunes store on the Mac and then the Mac App Store on the Mac and then the iTunes store on iOS, not to mention iBooks and all the other stores in the ecosystem. So probably it doesn’t make sense to implement the checkout process in Objective-C and then also JavaScript for the web and then we have Swift – probably it makes sense to keep it all in one place.
CHUCK:
Yeah, that makes a lot of sense.
I want to change gears a little bit – we don’t talk a lot about them on the show but you’ve got the “hybrid apps” which are built on things like Cordova. So Famous is built on Cordova, Ionic’s framework was built on Cordova. You’ve heard of PhoneGap which is the precursor for Cordova before Apache adopted it and then they change the name. So these all use a WKView that's full screen – I think I’ve mentioned that before.
What are the tradeoffs between building something in his web technology stack versus using something more along the lines of what we traditionally see with Swift and UI Kit – things like that.
CESARE:
To me, these sounds like business questions more than a technical one because –.
CHUCK:
Now you sound like the guys I Ionic when I talked about then and asked them the same question is, “Well, ugh.”
CESARE:
The reason I say that is because during the Olympic Games – I guess last year or two years ago; that's a huge event so I imagine myself, I would’ve built so many different apps for such a big event at such a short time. And, spoiler alert, they went all web. But the point is the application was available everywhere. And when I say everywhere, I mean even on some Nokia 8210 which I used to use ten years ago or even more, or even 15 years ago.
So in that case, either you have a stellar budget to build native applications for pretty much everything, otherwise it probably makes sense to go to common technologies like web technologies.
The application might not end up being snappy or exploiting the latest tricks in the GPU of the latest iPhone released a week ago, but we're talking about an event that happens every four years and lasts three weeks, so does it makes sense to make such a huge effort to build so many different native application? So that's why I'm saying it sounds like a business problem because if you don’t touch the problem that way, then you’re going to end up into really just wars between web developers and native developers and both sides have good points but I think it's going to be a never-ending discussion at this point.
CHUCK:
Yeah, the direction that I tend to stir people because I get asked this all the time, “Well, should I go native or should I use –.” I'm also pretty heavily involved in the Ruby community so I hear, “RubyMine or should I use Ionic?” because they do Angular or, “should I use something else like PhoneGap, Cordova – just plain Vanilla whatever, or should I go with something else that's also cross-platform?” And the conversation i usually wind up having with them boils down to what does your web team use right now? Or what technologies are you familiar with right away? And the reason isn’t because I don’t think that native apps necessarily have a better or worse feel to them. They don’t have the experiences necessarily that much better or worst one way or the other. It just boils down to what you need.
The other thing is I often am telling them, “Look, you’re going to learn all the lessons you need to learn about having a mobile app by building one.” And so why invest all the time, trouble and effort into learning a new technology on top of that when you can learn it right away using technologies that you are already using and then you can build it up from there and figure out ‘Oh, we actually do need these couple of native APIs and we can’t get to them through the web view that we get from Cordova.’
Or we have some users that are saying that there's something funny about the experience that they’re getting out of the application or something like that. In the mean time, you fought through all the issues of ‘how do I get into the App Store? How do I get penetration on Android? How do I get penetration on iOS? How do I let my users know that stuff's out there? How do I interface with the APIs on my server online with this application and things like that?” And then from there you can figure out, yeah, we probably do need Swift. Or you may find out everybody seems happy with this or it would’ve cost us three times as much to do Swift because we didn’t know we would’ve had to train people on it.
CESARE:
Yeah. Different versions of all these discussions, I’ve been part of them. And so yes, I guess the sanest way of tackling the problem is probably putting it into the perspective of business. Otherwise, go with your guts or say you’re a web developer and want to discover Swift and how it works. Do it as a side project, no problem, but really there are no hard reasons for which you should or should not do it.
CHUCK:
Yup. The other thing that I run into a lot is they want to outsource it and they’re asking me what technology they want to use. And I just look at them and say, “Well, who's going to maintain it long term; the contractor or you?” And if they’re going to contract the maintenance long term and they don't really have technological connection to any of these things, then I just tell them to go with whatever the contractor’s going to do and then just make sure the contractor can do what they think they want. And again it just comes down to the fact that you're trying to solve a business problem and the technology is a secondary decision to that as opposed to anything else because then you're making a decision on can it do what it needed to and beyond that it doesn’t really matter which one you pick because there are plenty of people out there doing whatever technology you pick unless you pick something that’s really, really old or really, really bleeding edge.
CESARE:
Yeah, exactly. So one other thing that I have run across while learning a little bit about JavaScriptCore – and you mentioned it earlier with iOS 8, there are a whole bunch of performance upgrades that came into it and things like that. So what is it about JavaScriptCore that makes it so powerful at this point and what kind of performance and other upgrades have we seen over the last little while?
CESARE:
The biggest upgrade happened last year and yes the genius part of it was tying the optimization phase into LLVM. And so exploiting what is already happening for Objective-C and Swift. Essentially and being very succinct, reusing the optimization techniques already in place for Objective-C and Swift and apply them to JavaScript as much as possible. Because again, we're talking about two pretty different programming languages because JavaScript - it's [inaudible]. You can even instantiate different virtual machines – Java and virtual machines. They cannot talk to each other and exchange – the context within the machines cannot exchange information but within the same machine, for example, you can have different context and they can talk to each other so maybe you want to create an instance of context that does some background processing and then notifies the other context when the calculation has been performed.
But it feels like now you can build your own WKWebView. Of course it doesn’t make sense because we already have it but if you wanted, you could. So just by following a few simple rules and establishing this communication between the two sides, the two I would say cores within iOS.
CHUCK:
That’s really interesting. And just to clarify, when we were talking before, you mentioned LLVM and LLVM is a compiler infrastructure. It’s basically a way of compiling technologies or compiling languages down to machine code and the thin that’s interesting about it is that Objective-C and Swift both use LLVM and that’s where Cesare was saying that people can actually then – since JavaScript uses this as well, they can optimize it in the same ways that they optimize the other languages that they have adopted or created.
CESARE:
Right. More or less it goes like this. So if the engine of JavaScriptCore detects that a function has been called – I think the magic number is six times – it switches from the first tier to the second. And then if it detects, it has been called more than 60 times, it goes to the third tier and so on and so forth until it goes to the latest one which generates very highly optimized code but of course, the optimization takes some time. So that’s why they have this step up process of optimization.
CHUCK:
Right. So it’s being called once or twice, it’s not necessarily worth doing the extra work to compile it but if it’s used six or so times, then the trade-off starts to make sense where if we compile it it’ll actually make it three times faster or five times faster or something. And if we do the next level of compilation, then it makes sense because we’re doing it at 60, 70, 80, 90 times and so we want it to be super high performance and not costs us as much on the resources on the machine, which in this case is a phone or a laptop of something.
CESARE:
Right, exactly. It’s not just the number of times; sometimes there’s also number of loops are taken into account. But yeah, I would speculate that for example, the iTunes Store application ships with all the JavaScript code already optimized to the fourth level because it’s pretty that – you can be pretty sure that you’re not going to change a lot of code when you share a new version, a major version of iOS. Again, just speculating but it might make sense.
CHUCK:
Yup. That’s really, really fascinating. I remember building projects that we compiled with LLVM compilers in college. So just seeing it in use in a real world application, especially with JavaScript just kind of geeks me out a little bit. It’s really, really fascinating.
Are there any other things that people should know about JavaScriptCore?
CESARE:
Probably I didn’t mention yet that you can even organize your JavaScript code using exports. If you’re familiar with [inaudible] or dynamic libraries that you compile so that they can be used for other programming language interpreters and so on, you can do the same in JavaScript so you –.
CHUCK:
Oh wow.
CESARE:
Yeah, even more awesome – for example, you can create an object so you can define an object in JavaScript. And you compile your application and then you will be able to use – so create instances and call methods on that object in Objective-C or Swift.
There are a few draw backs, so for example the properties will be dynamic – marked as dynamic because in JavaScript you can define a class and then change its properties, add or move properties. Things can go crazy so that’s why variables are marked dynamic by default exactly like in Core Data. But yeah, it’s crazy.
So you write, you define the model in JavaScript writing JavaScript code and then you use that model in Objective-C or Swift, and you can do of course vice versa. So you can use the clear modelling in Objective-C and then call method on instances of that class from JavaScript. It’s crazy if you dig in.
CHUCK:
That’s really cool. One other thing I want to ask about is you mentioned doing background work in JavaScript. So do you just spin up a JavaScript process and then feed it the information it needs and then it just pulls the code in from wherever it has its JavaScript assets and runs with it?
CESARE:
Yeah, it would probably make sense to have it to use GCD and then all the native infrastructure that we have to perform background processes on iOS o the Mac but technically, yes, you could.
So let’s say that if you had a cue system written for Node.js, I would speculate you could run it on a Mac or on an iPhone. It may not be the wisest choice but I think you could do it.
CHUCK:
I’ll admit to knowing a few people that if it can be done in JavaScript, the will do it in JavaScript. [Chuckles].
CESARE:
Yeah. There’s only one – well, there are a few tricks when you establish this communication between JavaScript and the native side of things. For example, a JavaScript context always keeps strong references to the variables that it declare. So you should – if you want to avoid leaking memory, of course you should [inaudible] self if you need to call it from within a block and you should avoid to make reference to the JS context and use the function JS context, current context if you need that within a block.
But apart from that, I see there’s a pretty neat integration. There’s even an exception in handler which is especially a block, a special block in the JS context that you can use. So whenever you have an exception in JavaScript, of course you’re never going to see anything in the native console in Xcode but if you set up this handler, you will see JavaScript code printing issues in the native console in Xcode. What else [inaudible]?
CHUCK:
Yeah, I’ve used that before for myself so I’ve had issues in Safari on my iPhone, loading a page that I built and have been like, “Okay, how do I debug this?” Essentially, what I had to do was I had to connect it to my Mac and I don’t remember exactly how I did that. But then the web console that you’re used to in developer tools on your desktop machine essentially becomes available to the bowser on your phone. And then you can actually see the errors get hit and you can see what’s happening, you can see whatever your logging to the console, etc. and have it come up in those developer tools on your Mac.
I’m assuming that’s what you’re talking about. Is that the same functionality?
CESARE:
No, I was talking about something different but yeah, that I don’t know if there’s some JavaScript involved. What I was talking about is say that you have your native application and there’s no web view involved. You have some JavaScript code that you want to execute so you bundle the JavaScript code in your application, you load it using Swift and then you call it using Swift. And maybe you even set up some call back on that call but if the JavaScript code fails for some reason, you don’t get anything printed on the Xcode console. Whereas in Objective-C or Swift, there’s something wrong, it crashes or it throws and exception. You can set up a handler which is called exception handler on the JavaScript context and it will use that sandbox for JavaScript to send errors back to either Swift or Objective-C.
CHUCK:
Gotcha. So then you can basically log out whatever information you need to the same way that Swift or Objective-C does.
CESARE:
Exactly.
CHUCK:
Huh. Cool Alright, well I don’t know if I have any other questions. If people want to learn more about this is there some kind of a central location for that?
CESARE:
There are a few talks spread over the last three years at WWDC but definitely, I would suggest going to asciiwwdc.com website and run a search for JavaScriptCore because they can even go back to 2010, some of that but the concepts presented are still relevant nowadays. Unfortunately, JavaScript code is not a pretty hot topic – everybody talks about Core Data or Auto Layout or size classes at conferences whereas it’s pretty rare to see and talk about JavaScriptCore. But I would keep an eye also on the WebKit.org blog; they post very detailed and interesting posts about optimization and JavaScriptCore, even CSS. And for example, if you want to know whether or not they’re going to release something ne next year in Safari, if you keep an eye on WebKit.org/log, probably you could have a glimpse of what will be included in the next release.
What else – I don’t remember any more source of information about JavaScriptCore.
CHUCK:
Alright. Well, let’s go ahead and start wrapping up. We’ll go ahead and do some picks. I’ve got a few picks; one of my first picks is Highrise. I don’t remember if I mentioned it last week or not but I’ve been using Highrise to manage all of the outreach that I have for different things in my business. As you may or may not know, I make a bunch of my money from doing the online conferences and I am planning on doing an iOS Remote Conf next year and I’ll be announcing dates on that here within the next week or so. So I’ve been using that to reach out to speakers, sponsors and things like that, or people like that – they’re not things sorry.
The other thing that I’ve really been enjoying lately is the Ionic framework and I’ve mentioned it a few times here and that heavily uses JavaScriptCore. So if you want to go check that out, you can check it out at ionicframework.com.
Cesare, what picks do you have?
CESARE:
I just have one but it’s pretty important to me and that’s podcasting because I rediscovered that – it’s been around for ten years or even longer probably but the first pike was ten years ago more or less when I wasn’t included in the iTunes. And I kind of ignored that and then I rediscovered that two, three years ago and then I’m into it like crazy that I wake up and listen to podcast, watch and listen to podcast, walk the dog and listen to podcast. And I really, really, really like it much more than radio, for example.
CHUCK:
[Chuckles] Yeah, I’m in the same boat. So do you have a podcast then?
CESARE:
I will take over soon the CocoaConf podcast, so the podcast related to CocoaConf which is a conference about iOS and Mac development in the US.
CHUCK:
Alright. I’ve actually, since you brought it up, I’m working on a book right now on podcasting. It initially started out as the book for people who want to just start to podcast on Deevchat.tv. And we have a couple of new shows that I’ve mentioned previously – Web Security Warriors and React Native Radio which I’m not running your hosting but are going to be on the show. So I started out writing a podcast manual and then I had other friends in other areas come to me and say, “Hey, you do this podcast. Can I get your opinion on what I’m doing with my podcast?” And that turned into this massive podcasting book as I’ve realized that I’ve put together a whole bunch of information about podcasting that I now need to consolidate to one place.
So if you want information on that, you can find it at pickuppodcasting.com. The website isn’t up now Cesare but it will be by the time that people get this episode. So if you’re interested in that, you can check it out.
I also have a friend who’s looking at doing a hangout on air for her customers and as soon as I have information about that then I will let you know so you can actually listen to me talk about it. But yeah, podcasting stuff is awesome. I really think it is part of the future of content not just on the web. As people realize that you can get the big corporate – I don’t like corporate but the big media companies like ABC, NBC, CBS – I don’t think they’re going to go anywhere but people also realize that it’s not just the mass media but it’s specific media to what I’m interested in and what I want to hear about. As people figure out that they can get that stuff, I think that’s also going to be the future. So podcasts are going to play a big role in that so I’m definitely looking at that but yeah, you can check all that out at pickuppodcasting.com.
And that’s enough of my self promo. We’re going to wrap up the show. Thanks Cesare for coming.
CESARE:
Well, thank you for having me. Always a great time on iPhreaks.
CHUCK:
It’s been really fun to just talk especially about this because it mixes two of my kind of passions in programming, that being iOS and JavaScript. So yeah, super fun.
[Hosting and bandwidth provided by the Blue Box Group. Check them out at BlueBox.net.]
[Bandwidth for this segment is provided by CacheFly, the world’s fastest CDN. Deliver your content fast with CacheFly. Visit cachefly.com to learn more]
[Would you like to join a conversation with the iPhreaks and their guests? Want to support the show? We have a forum that allows you to join the conversation and support the show at the same time. You can sign up at iphreaksshow.com/forum]