The panelists talk to Moodboard's creator and CEO, Christopher Nurre.

 

So I want the iTablet and the iWatch. Or Apple watch. Or iWatch. Or whatever you call it...

Hey everybody and welcome to episode 72 of the iPhreaks Show. This week on our panel we have Andrew Madsen.

Hi, from Salt Lake City.

Alondo Brewington.

Hello, from North Carolina.

Jaim Zuber.

I've already got my iPhone 6.

I'm Charles Max Wood from DevChat.tv and this week we have a special guest, and that’s Chris – is it Nurre?

Nurre, yeah, you got it pretty close. Hi from Cleveland, Ohio.

Awesome. I think we’re just missing a central time on the show this week. Do you want to introduce yourself really quickly?

Well, my name is Chris Nurre. I've been doing iPhone/iOS development since they released the SDK. I worked with one other guy and formed a company called aTinyTribe. You can find us at atinytribe.com.

We have a handful of apps, but our big one is MoodBoard. It’s geared towards graphic design, but pretty much anyone that wants to make a collage of images, texts, colors – anything that’s going to inspire them for a project – and help them make it better.

So it’s Pinterest for geeks.

You know what? I won't even say for geeks, because we have people that do weddings on them; we have people that do vacation collages, technical things. It’s been amazing, the different things that it’s been used for.

Nice. It’s really interesting; we actually brought you on to talk about that app. When I was introduced to you, they said that you had done some stuff like resizing images and stuff that you had had to deal with things like that.

Mm-hm. That’s probably one of the biggest challenges that I've had to tackle, and this was way back when with the iPad, which was severely limited in resources and the ability to load an image whether you took it from your DSLR –. We didn’t have iPhones with such great cameras at the time, that to be able to process that, not only in a quick way, but to maintain as high of a resolution as possible.

MoodBoard offers the ability to kinda zoom in into the actual image, to the point where you can see detail at a very high resolution. The challenge was, how do you load an image that is twice the size of the pixels of the iPad screen at the time without exploding the device? I mean, literally to the point that the device completely crashed and had to be restarted. So I was blowing through memory real quick. And that’s one of the challenges of image processing in general. You never realize how much – even if it’s a 1MB jpeg file, even though it’s compressed, when you have to dump it onto the screen, it can take up a ton of memory, right?

So is it a memory issue then? It’s not a library issue or some other performance issue?

No, it’s strictly a memory issue. The way to think about it is, you could have a jpeg image – let’s say it’s 1920x1080. That’s probably about a few hundred KB in terms for file size. You go into finder, you do a git info and it shows it’s only 300KB.

Unfortunately, when you have to push something to an iPad screen or an iPhone screen, or pretty much any type of screen, it’s got to take every one of those little pixels and those are represented in blocks of memory. You basically have to take the height and the width and then multiply it by four. This isn’t necessarily a completely scientific algorithm, so please send your complaints elsewhere. But when you do that, you end up with that same-size image that was, say, 300KB to something that equals 8MB in memory on the device. Well you do that, and you do that times 20 some odd images, it starts to add up really quickly. And so [crosstalk] –.

I've done this with devices as new as an iPad 2, and things go down pretty hard when those happen. You don’t get a nice error – you crash.

Oh no, you crash the entire device sometimes and you don’t even get error warnings. It’s actually kind of – it was entertaining at times. The first time I did it was I got the little Apple logo that you see normally when you restart it, and I'm going, “What did I just do?” [chuckling]. I mean, literally to the point that the device had no idea what to do that it goes, “Alright, I'm restarting.”

It’s not pretty; it’s not a pretty thing and we had to do this primarily without touching the device at first, too, so that was the other challenge. Because when the first iPad came out, none of us developers had access to the physical device; all we had was a simulator, which added even more challenge to –. The simulator does a good job of showing what it should look like on the screen, but it doesn’t do a great job of simulating the hardware that it’s going to be on.

This was something that immediately became evident when the iPad came out. You have that magical unboxing and you go, “I need to get my app on to see how it actually works,” and you go, “Ooh, uh-oh.” That was the big first update, definitely, was handling some of these images.

Through the process, found some algorithms in terms of piecing different techniques that I saw from other places; none of them were iOS or even Objective-C specific or Apple-specific, doing a method of taking chunks of the image one at a time and presenting them to the screen so you only had that little bit of chunk in memory at one time, and doing it that way. That allowed for the iPad 1 to show a 70 megapixel image that I found from NASA.gov.

I was curious, I was thinking sometimes finding solutions to the problems you have that are maybe outside of the domain that you used to [inaudible] – what sort of [inaudible] sort of look in these places where there are other entities or are areas where image processing was a challenge as well, or did you sort of stumble upon it or what?

Well, you know what, it came around in that I first kinda found out about CATiledLayer, which is something that Apple provides in their core animation framework. That was the first thing that got me thinking, “Okay, I can tile an image, right? I can take that and CATiledLayer has its own intricacies of doing things kind of an asynchronous step-by-step process of ‘Here’s a tile, let’s display it; here’s another tile, let’s display it.’”

And so that got me thinking, “Okay,” so that’s the first technique that I started, and really it was a matter of figuring out how to get the tile and playing around with different sizes. Do you go for a tile that’s 128x128 pixels, or do you go the entire width of the image and only do 10 pixels tall? Do you do a grid, or do you do something vertical, something horizontal? And a lot of it was trial and error, trial and error, and also a lot of it was just diving into frameworks and lower-level core graphics of things that I didn’t even know. I didn’t have experience with image processing or even low-level core graphics at the time.

Yeah, something like that can be daunting. For instance, I'm not really strong when it comes to those libraries, and there's a bit of intimidation there, so it’s good to hear that you can solve these problems by just going and taking this step-by-step [crosstalk].

Mm-hm. The other thing that helped – and this was the first time that I ever used it – was I actually used one of the Apple developer services, whatever they call them. Each year, as an Apple developer, you get to work with an engineer for two different instances. I had finally gotten to the point where I go, “There's got to be a way – obviously the photos apps seem to kinda hold this image and it would display it; why can’t I do it?” Sent out the email, finally bit the bullet, and even as the engineer that I got hooked up with – he was kinda stumped at the time. We looked at it back and forth and like, “Hey, how about we try this? Hey, how about we do this?” which actually ended up being part of some sample code that is part of the large image downsizing that was posted a little bit ago. It’s actually a little outdated now because there's been some updates to some of the frameworks, but overall, it gives a really good idea of basically what the app does and how it chunks out images and loads them into a CATiledLayer. You can find that under the developer portal under Apple.

I think that brings up – we’ve used those technical support incidents in a couple of instances, but it also reminds me that we had a very similar problem, or we had really huge images and they were actually images that were scrolling but many times the width of a device screen. We had these exact same kinds of problems with huge memory usage causing the app to terminate and it took me a long time to figure out how to go about doing that without running into memory problems but also while keeping scrolling performance really high.

I was talking with an Apple engineer at WWDC that provided the breakthrough, and I think a lot of iOS developers don’t really think about those tech support incidents, and you get to a year so you might as well use them.

Absolutely! Yeah, it’s paid for; it’s right in your account, so why not, right? I mean, the worse it is is you wasted an email. The Apple engineers have always been helpful when I've had an issue and kinda needed to work something out.

So what are some more memory management tricks with images?

The big thing was the chunking and sticking within aligned memory blocks.

What do you mean?

Computers themselves want to stick within a certain number of bytes; if you have things that aren’t aligned –. You always hear the numbers: 128, 256, 512 – sticking within those ranges, they tend to read images in that sense as well.

The big find that was the precursor for figuring out how to take a silly large image and take a chunk at a time, was using a core graphics call called CGImageCreateWithImageInRect, and that rect would take an image that you already have loaded via URL or a path and you can call the different rects. If you kept the rectangles within those particular ranges of 128, 512, 256, the performance was much better. There were times that I would go in and try to load something that was, say, 500. 500 is just a natural, comfortable number as a human, whereas 512 was faster if I did it that way. It was because of how, deep down, even beneath core graphics, there's ImageIO which [inaudible] the loading of the image and decoding of the image from file and then how it processes the actual image and all that.

There was a lot of trial and error of doing that. Honestly, a lot of it is trial and error. You have to be willing to go, “Alright, this sounds stupid, but let me try and do it” and then use instruments, test, retry something else, test, retry something else, and that’s really where it was as being able to find the balance. Even between different devices. The difference between the iPad 2 and an iPad 1 was significant, so the actual algorithm that it uses is slightly different. It uses bigger chunks on the 2 versus the 1 – the 2 and greater.

So do you end up managing the different chunk sizes [crosstalk]?

For the most part, it is just a check for the retina screen or not. At the time when the retina – between the two, there was just the check of the device, and then then the retina screen came out, you have even more of a challenge because you have four times as many pixels that you're managing, which means you have four times as much memory.

There were times that you actually almost had to go lower in resolution because you were putting so many different pixels onto the screen. The graphics – the memory and the graphics processor weren't necessarily up to speed at the time especially with the iPad 3, that since kind of been improved as they’ve updated the line.

Yeah, I've seen this on an application I worked on a year ago, when we started using newer hardware with retina displays, performance went down. We’re like, “No! That’s the wrong way! It’s supposed to go the other way! Newer hardware is supposed to be faster.” But if you're doing [inaudible] graphics, intense stuff, it can actually be slower, so it’s a good thing to keep in mind.

I'm not sure if we got a direct answer to this, but do you actually then just resize the images to fit in those memory blocks, or is there some other approach that you're using to – do you just resize it in memory? I'm curious.

The way the app in the App Store right now works is it takes the very large image and it will chunk it down – not only at the 100% scale, but it will also do it at a 50% scale and a quarter scale. That way, as you zoom in and out –.

If you're showing, say, an image that’s twice the size of the iPad screen, but you're showing the entire image, that’s really the image scaled down 50%, so you don’t need to be showing the full resolution because you're never going to get the fidelity anyway. I actually go through and do the 100%, the 50%, the quarter, the 25% so that way, depending on how you have an image zoomed and how it’s being presented to the user at that time, it will choose the correct image and display that as the tile instead. That was another way that, especially with dealing with a large number of tiles, if you only have to show something that’s 50% resolution, you speed up not only going back and forth on the disk but also just in presenting it on the screen. So that was another big thing.

The other thing that I kinda learned and kinda learned again by trial and error is the work that the Apple engineers did – they're very smart. They knew and understand when the system is under stress. If you have something like a CGImage or a CIImage, or even a UIImage and it’s backed by a file, it will naturally release memory if it can’t hold it. And then if you make a call to it again, it’ll go back to the disk and that’s a performance hit, but it’s not crashing at least. And so there's this kind of teeter-tottering of how much do you allow in terms of performance versus not crashing and all that as well.

Yeah, that makes sense.

We talked about displaying something an image that might be twice as big as the screen, but you don’t need all the resolution – did you do anything with scrolling where you're actually displaying things, a smaller part that has to be expanded?

MoodBoard in general can have a large number of images at any type of scale on the board. Say, we’ll just deal with one image; it’s just a background image. It’s twice the size of the screen, so if you zoom in all the way to viewing the image at a hundred percent resolution, you're only going to see a quarter of the image. That works really well with CATiledLayer and you can actually then scroll, say, from right to left and the tiles that are off-screen will load in asynchronously as you move around and the ones that go off-screen then get dumped, so you don’t need that memory footprint. You don’t need the footprint of the entre image; just kind of a viewport that you're looking at. That’s one of the techniques that you can do to save on it. You'd only need to load in a subset of the image, and then if you want to pinch out and zoom the whole image, you can do that – or twothirds of the image, or however it might be. It’s a variable scale of both the position as well as the scale.

CATiledLayer – it’s very poorly-documented in my opinion and it had some issues early on, but it’s a remarkable tool and probably an underutilized tool, I would say.

What did you do to get the word out about this app?

You know what, not as much as you would think. I got really lucky or good – I don’t know. I worked really hard to get it to be one of the first apps out for iPad only when the iPad came out, so that was one of the first things. We were in a very small marketplace at the time, and sent out some press releases, sent out some fliers and some requests to be interviewed and get reviews by different blogs – Apple blogs in that – and got really good response.

From there, it kinda took off. It was that lucky enough that Apple chose MoodBoard to be featured a number of times in both the US store along with international stores, and then got some pretty good reviews from different Apple blogs around, and then kinda got some word-of-mouth also via the educational discounts. We set our app to be educational discount so that way educational institutions can buy them in bulk at a discount, and then we’ve actually had the app used in classrooms. That’s been a really neat thing, to see how teachers and professors are actually using it as a teaching aid, whether it be a graphics class or a graphics design class, or just other things. That’s been kind of our motto of, “You know what, make this something that you're going to be proud of and make it do something really well.” It doesn’t have to have 5,000 bells and whistles, but make it do those one or two bells and whistles really well, and the response has been great.

In terms of direct marketing, we hadn’t really done much. Maybe that’s an anomaly, but I normally fall under the lines of, “You know what, if you're going to do something really well, you'll get noticed at some point. It might not be right away, it might not be as soon as you want, but quality gets noticed,” and so that’s always been the driving force behind MoodBoard.

How do you keep in touch with your customers to know what they're doing with your app?

A lot of it’s email, some Twitter, but a lot of email and Twitter. Also just seeing – we’ll notice tags on Flickr or Instagram where you can tell that it was used on the iPad by the app, just based off of some of the stock backgrounds and things like that.

The other thing that we’ve had and it’s been kind of interesting – this was something that was totally not expected, but we've had a number of television programs contact us and they are actually using them in their television shows.

Oh, cool!

One of them would be the PBS show, Genealogy Road Show. They will go through and find images – it’s all about finding your history and your genealogy for a particular person in a segment. They projected the app onto an Apple TV and a TV that’s close by and they use it to present images of their history, whether it be their grandfather or great-grandfather – something like that – or mother, whatnot. That was really interesting because it was something that was never even anticipated that would be how it will be used.

Do you keep marketing your app?

We do. It’s been a little dormant recently, kinda waiting on the iOS changes. I definitely see there being some opportunity to jump down into the iPhone.

The iPhone is the most popular camera phone, or the most popular digital camera, just in general. And so to have an app that can take pictures and move pictures around in your pocket, it’s a great opportunity. The size has just been the limiting factor.

Yeah, I'm looking on the site on iTunes, it looks like your last update was 2012? So you’ve had a pretty good run without having to do a whole lot.

Are there any changes that you're going to need to make for iOS 8?

The changes in iOS 8 are going to be more utilizing what iOS 8 brings. The better ability to share files with iCloud; the better ability to have your stuff across all devices, whether it be on your iPad or your iPhone – if there is an iPhone app *hint, hint* [chuckling].

So that, along with some of the sharing features, investigating some of the image processing features – there's a lot of great apps that allow you to add filters and different things that they are much better at doing than MoodBoard is capable of doing – so taking advantage of that and being able to inter-operate with other photo apps is a huge opportunity. That’s kind of a big deal right there.

The iCloud is probably the biggest thing. In terms of exact changes, the app itself has been pretty solid; it hasn’t had any major issues with iOS 8 recently. We shouldn’t have too much in terms of short term, but looking long term and upcoming in the next few months, definitely have some big plans.

I would love to experiment, but I don’t really know if it’s going to be possible or what, but experiment with HomeKit. I think there is a huge opportunity for – I mean, the app’s called MoodBoard; it’s supposed to inspire you and get you in the mood for whatever you're working on. Just imagine the ability of – as you add images and as you add colors – it automatically changes the colors of the room, of the lights in the room. Those are some opportunities that, well, it might seem gimmicky at first, but there's definitely something that might be there. Again, that's way down the pipeline in terms of what's possible. But I think these types of things with HomeKit and HealthKit, even completely unrelated, but developers and the opportunities for apps to make use of it is - I don’t even think we have a good scope of what is possible now.

It’ll be interesting to see where things go.

Oh, absolutely. I really do believe and I hope – and maybe I'm wrong; I've been wrong before – that developers do kinda hit the ground running on some of these new things in iOS 8. I think there is a large opportunity for new ways that we interact with our technology.

The Apple watch just now is kind of one of those things that kind of borders between a device that we use versus a device that we live with. I mean, we have our phones all the time, but it’s in your pocket sometimes; it’s on your desk. The watch right there, it knows when it’s on your wrist. We’re blurring the lines of technology and experience, and I think it’s kind of a fun time and a fun thing to be a part of.

You can think of how far we've come in mobile technologies in six, seven years, but we’re still – we’re very much at the beginning of anything.

Absolutely. You think about just how we’ve gone from the ideas of skeumorphism and duplicating physical things on a flat screen – just in the effort to maintain familiarity – and now we familiarity with pinch-to-zoom, which is something that never really existed in the physical world.

We have this whole concept of holding up a phone so that way we can chat with someone else that’s halfway across the world. It’s making the world smaller; it’s also making the world more entertaining; it’s making the world more engaging, and these are all things that are very possible.

It’s an incredible time, it really is, and I can’t wait to see what other people come up with.

So do you think the skeumorphism was just a temporary step?

In a way, yes. There's nothing wrong with maintaining familiarity. I don’t believe that there was anything directly wrong. It’s when it got absurd; it’s when it got to the point of skeumorphism was actually limiting the ability to do something better. You have the leather and the paper jagged edges and all that, and those take up some space, or maybe I could put something else that was important on a calendar, something that’s not normally there. That’s where skeumorphism got in the way.

Now I will argue something like iBooks, where yeah, you have the page scroll and all that, but dividing it up into pages I don’t think is necessarily a bad thing; I think it’s a very natural way of ordering and reading a book. I guess the ancient Greeks and all that, when they were reading things on scrolls, were probably saying bad things about books at the time, but it was a natural progression. There's a visceral reaction that you have with certain skeumorphism metaphors – skeumorphic metaphors – and that connection with you and the technology is kinda what's keeping you engaged, what keeps the user engaged. It’s just a matter of not going too far, because you can put the user off too.

I have a question about that in combination with what you said earlier about sort of getting featured in different markets, are you seeing a difference or are you getting feedback that maybe as the proliferation of these devices starts to grow into some of these other markets? I know there's a concept of like the next billion users – is there a challenge there with a large segment of users who may be acclimated to a lot of these metaphors or gestures and those who aren’t? Does that hinder you in what you see taking the app in the future? Do you have to sort of hold back to make sure everybody else can catch up, that hasn’t really kinda – the societies that aren’t quite yet used to mobile devices?

Yes, absolutely. There's also a point though of, sometimes there's just got to be multiple ways of doing things. You can have on your iPhone, when you're looking at your mail and you can swipe to delete a message now, well you can also hit that little edit button that’s up there and delete them normally too.

Sometimes it’s a matter of finding ways that might be the power user way of doing things but not might necessarily be discoverable, but also offering opportunities for people that like to do in a step-by-step manner – something like pushing an edit button then hitting the ‘x’ to delete it or whatever. That’s usually – try not to make a feature so hidden that no one knows about it. If you have to point it out and put it like a, “Hey, look at me!” or “Hey, here’s the help on how to do this” then you might have gone a little bit too far one way.

That’s the challenge of especially being technically-oriented; you just naturally say, “Oh, what's so hard about a swipe from right to left?” Well, some people don’t even know that exists. And you also have the – you have people that are differently-abled that a swipe from right to left might be actually a difficult, physical motion. There's all sorts of different users; you want to build something that just about anyone can use, and that’s a challenge you could try and balance and take it to someone that you know is not necessarily technically-inclined and without saying anything you say, “Hey, what do you think? Try it. Do this. How do you think you should delete this?” or “How are you going to add a new image?” and just watch and observe. Because ultimately, it’s about making something that other users enjoy, not necessarily you. And absolutely – it’s an absolute challenge.

I can’t count the number of times I've had arguments in different projects, whether it be my own or other ones that I'm working on or even other people’s that want input as to what is obvious and what isn’t. I think it’s a challenge no matter what type of app you're working on.

Yeah, but since you’ve got a pretty good approach, I like the idea of saying, sort of not holding back the more advanced users by taking advantage of gestures, but providing those cues for people who are not necessarily savvy. You don’t have to draw a line in the sand that prevents you from really exploring new interactions.

Mm-hm, absolutely. The thing is is that in a process, you can maybe teach them, “Hey, next time if you want to delete this, swipe right to left.” The more you get someone to use it the better, especially in this day and age where apps are kinda a dime a dozen and people download them as quick as they drink a cup of coffee, they're just as likely to say, “You know what? I don’t like this, I'm deleting it.” You don’t want to frustrate anyone either. You frustrate someone within the first five minutes of using an app, odds are is you're not going to get a good review and you're not going to stay on their device. No matter the number of updates that you do, if you're not on the device, they're not getting and update and they must go and re-download the app.

So how do you test that people are using the app the way you think they should?

Some analytics, some – just very general though. I try to stay away from the I-need-to-knoweverything-about-you-what’s-your-mother’s-middlename-the-last-four-digits-of-your-social-securitynumber just so I could make the app better for you. That just seems way too invasive and just way too inappropriate. It’s not necessary. A lot of it is feedback; a lot of it is just direct feedback of emails back and forth, “Hey, how are you using this?” or people sharing, “Hey, I've been using it this way for the last few months and I love it!” and that’s a great thing.

Thankfully, the app in general is relatively simple. You have some collections of boards that you can filter out; they're groups of boards, you pick your group, you pick the board that you want to modify, and you open it. From there, it’s whatever it is. You can add images, you can add text. So we kinda have an idea of how many images are averaged on a board, or how many pieces of text or stuff like that, but beyond that, it hasn’t been necessarily geared towards one type of user or the other. It’s, make it as easy for people who want text as other people who just want images and try and meet the happy medium there.

I'm not a huge believer in being overly analytical of, “Oh, this person added two images and then one piece of text and then one other image and then closed it – it doesn’t really give an insight or a feel as to what the user was doing. For that, you kinda just have to engage them. It’s not that type of app; it’s a feeling app more than a technical, very analytical app, I guess, in very generic terms.

So we need a way to [inaudible] how a person’s feeling by using the app [crosstalk] or something.

CHRIS: iWatch.

Oh, there we go.

That’s right.

The Apple watch.

It’s coming!

Yes, the Apple watch, excuse me.

I keep making that mistake and I keep saying iWatch and I'm like, “No, it’s not the iWatch.”

I'm usually the guy that gets kind of annoyed when people call an iPod touch an iTouch, that kind of thing, but I keep calling it the iWatch because that’s what everybody’s been calling it for six months.

Yup.

Oh sure.

Yeah, I'm just excited to see what it can do.

It’s going to be interesting. Like I said, it’s going to be interesting to see – I mean that's maybe a little too invasive, but could you imagine an app that actually is able to take your pulse? Say it’s a

game or whatever it might be, it reacts to your pulse and that’s how it changes the interaction. There's all sorts of different things, but maybe that’s a little too creepy for an app like MoodBoard, but the possibilities are endless.

Yeah, but the thing that’s interesting about it though is I really want to see how good the sensors are before I'm super excited about what it could do.

True.

Because those kinds of sensors, I've seen the wristbands that take your heart rate and things like that. Some of them are okay and some of them are horrible, and so it just depends.

They are fine until you get out and actually start running and get a little sweat going, then not so much.

Yeah, but then you have –.

[Crosstalk] going to use them; they're great!

But then you get the chest bands, and those are super comfortable right? We’re getting off on a tangent, should we do the picks?

Sure.

Sure.

Alright. Alondo, why don’t you start us off with picks?

Both of my picks are related to issues that have come up today. The first one is, there's a blog post from Atomic spin – is the name of the blog – and it had to do with animation. I've been trying to get some animation working with keyboards and auto-layout, and I was having a lot of difficulty getting the frames to stay in the right place and to sort of get a hold on the proper animation based on the orientation of the device, and this article really helped out a lot, sort of breaking things down. The only thing that’s missing there, I will say, is this is not auto-layout-specific; it’s still using frames, but you can make the necessary adjustments for auto-layout.

The second pick is a [inaudible] profile manager. We added a new iOS dev and we've got some provisioning profile issues and it was really difficult to kind of keep track within Xcode. We are using a new [inaudible] profile manager that helps us manage which profiles are expired and what we should be using where, and it’s really helping out a good bit to get a handle there. Those are my two picks.

Cool! Andrew, what are your picks?

Two picks today. The first is, it’s just an article that I read recently and liked. It’s about the Lego Movie, which I really enjoyed. It sort of talks about how they made the movie, which I thought was interesting. I think the interesting thing about that movie is a lot of people think that they made the whole thing with real Lego bricks, but actually they didn’t; it’s mostly computer-animated. It just talks about the process they went through to make that look really good, like it was actually real Lego. I like reading about this kind of thing where somebody puts in this much attention to detail in order to get things just right, so it’s interesting. It’s on a website called Creative Bloq, which I don’t read but I might start because this is interesting.

The other one is something that I'm sure has been picked several times before – that’s objc.io. They have a new issue out right now, issue # 16, which is actually all about Swift. Swift’s been out for several months now; I know a lot has already been written about it, but these guys get super smart authors to write their articles and there's always new stuff that even an expert has not heard before, or new things to learn, so I haven’t gotten through this whole issue yet but I'm looking forward to it. So, objc.io. Those are my picks.

Awesome. Jaim, what are your picks?

I'm going to have one pick. If you have a house and you need a watchdog, I recommend getting a terrier. My dog has been going nuts for the past five minutes while I've been on mute, probably barking on a kid walking home from school, but he barks at other stuff too. So if you want a watchdog, terriers – nothing’s coming near your house.

[Chuckles] Awesome, I like it.

That’s my pick.

Alright. I've got a couple of picks; the first one is a book called Hounded. It’s the first book in the Iron Druid Chronicles. I picked it up; I've had a few people recommend it to me. It’s kind of a modern-day setting, magic-type book – really enjoyed it. In fact, I listened to it on Audible in a day, so I'm going to pick that because I just really did, I really enjoyed it. I think that’s all I've got for this week.

Chris, what are your picks?

First, to piggyback off of the objc.io, I think it was their third issue – it has a great set of things on dealing with images. Go read that, because they have a lot of information that I wish was available when I was initially doing some of the stuff with MoodBoard. That’ll be, I guess, one, kind of a piggyback.

The other thing is I've actually been working on renovating my house. I recently bought a house and kinda going through and dogfooding my own app, but also seen how other apps might help in the process. One that I really found that I really liked is an app called Room Planner by ChiefArchitect. It allows you to lay out different rooms; you can actually add furniture, and then actually do a 3D walkthrough and paint the colors, get an idea of if you're remodeling the house as to what it actually looks like. It’s actually a free app, but if you want to add things like being able to have absolute dimensions and things like that, there's some in-app purchases. I highly recommend it, it was well worth the few bucks for the in-app purchases, and to be honest, I would’ve never gotten as far as I have with my remodel without that app.

The other one, as I'm doing this remodel, I found is called Garageio. It’s an app-enabled garage door opener, which will work on your existing garage door. You don’t need9 to go and buy another expensive garage door opener just so you can be able to use it with your app. It comes with an account that you can check the status of the door and all of that. That’s garageio.com and we’ll have that posted. That’s been a great little tool to kinda make my house more connected.

That’s cool. Alright! Well, just before we wrap up, if people want to get a hold of you or they want to get the MoodBoard app, where should they go?

Come to atinytribe, A-T-I-N-Y-T-R-I-B-E (dot) com. You can reach me, chris@atinytribe.com and there should be a link to the App Store. Or just go to the App Store and look for MoodBoard. All one word – M-O-O-D-B-O-A-R-D.

Very cool. Alright, well thanks for coming!

Thank you very much.

Yeah, we look forward to having you in the forum and talking to you again.