How good or bad an idea is it to write a book chapter-by-chapter, continuing on only if enough copies sell to cover costs to continue on for another chapter of writing?
If the playgrounds book taught me anything it is that writing for love (and I did love writing that) will not cover costs, especially for niche topics.
How would you set up a “pay-as-it-goes” writing system and what would be some gotchas? What price point for what might end up as a very short book? Could it turn purchasers into co-marketers, so they’ll keep getting updates?
Thinking of course, of an Apple TV book here, which seems pretty niche at this time. I’ll be done with the Swift Developer’s Cookbook very soon and am trying to brainstorm what’s next.
A post on devforums clarifies that tvOS apps will be standalone. You will not be able to build a universal app that works on both iOS and tvOS. However, you will be able to share code — assuming I can ever get my conditional compilation of #if os(tvOS) working.
Don’t confuse universal apps with the universal purchases mentioned in the write-ups: “Empower customers to enjoy their favorite apps on both iOS and the new Apple TV with a single purchase by enabling universal purchase for your app on the App Store.”
It looks like you’ll be able to create a bundle that sells with components for both systems, even if there are two actual apps that you’re building.
It should not come as a shock to you that Apple TV apps are not touchable.
Sure, you can use the remote and slide your finger around, but there’s no compelling real-world correspondence between the blank touch pad and the large screen it relates to.
When you design, you must design for relative interactions. Think “directions” instead of “points”. For example, “this button is to the right of that button, so shift the focus to the right” or “I want my toy to move up, so I’ll swipe in that direction”.
This is where gesture recognizers show great value and direct interaction like touchesEnded don’t.
Today, I decided to push the limit and see how much I could convey just using the blind touch region on the remote. The video shows my interactions. It’s okay for experiential messing around but kind of awful for any purpose.
It helped to reinforce that creating frogger-like games (such as the one shown at the event) is going to be an easier task that anything that involves indirect input like drawing or goal point setting. If you’re kicking around ideas of “what might be a good game to create”, this is going to be a huge design point to consider.
Think more GameBoy-style, side scrollers, etc than Drawing with Friends.
I’m also thinking this might be a good time to bring back the Graffiti-style text input code of yesteryear (not to mention file radars for Siri text input).
There’s some good discussion about UI focus on buttons, tables, etc. in the docs. Although my primary interest is SpriteKit, I think it’s time to kick the UIKit wheels around a little.
Today, while taking a break from my Swift book, I decided to set things up for Swift dev on the platform. When you live your life with cross-platform code, having to deal with a new platform is…difficult.
For the moment, I’m treating tvOS as a variation of iOS and converting all my statements that look like this:
to be flipped on their heads to test for OSX instead. It’s a huge pain in the neck.
In theory there should be a construct like if os(tvOS) but I have yet to figure it out exactly. Grrr.
You’ll want to design your icons and launch screen at a size of 1920×1080 and then trim down as needed. Leave at least 90 pixels to each side and 60 at the top and bottom to account for potential overscanning issues. Details are found at the Apple tvOS HIG.
I built my icons in Photoshop (here’s hoping El Cap won’t kill my Photoshop!) and imported them into the App Icon & Top Shelf image template. Not all image sizes are listed in the Identity and Type inspector so I had to hunt around a bit. To save you time, here are my sizes:
Front, Middle, and Back (Large): 1280×768
Front, Middle, and Back (Small): 400×240
Launch Image: 1920×1080 (see advice above)
Top Shelf image: 1920×720
For the Top Shelf (this is the MOOSE image in my video), make sure you design side-to-side with enough space and visual punch. This image has a big role in setting mood.
The front/middle/back sliced images are used to create some of the visual parallax effects. I designed mine all together in Photoshop layers and then saved each one to a different file. I think I may update Art Helper to make this easier.
Your launch image is stored in a separate slot in your xcassets folder so don’t forget it (I did initially) when setting up your art.
Point your browser here. Highlights follow. I automatically stripped anything that looked like a property/method but a bunch of things like keys did make it through my filter. Nothing hugely surprising jumps out at me from this list.
More general iOS 9.0 to tvOS 9.0 API diffs are here.
Touches lie in (0.0…1.0) in each axis and the pixels don’t seem to be square. I had to use SpriteKit’s node xscale property to adjust. Update:This is mostly taken care of by using initWithSize, making sure to take (in swift) the designated initializer chain into account.
Instead of using viewWillAppear/viewDidAppear, just stick with viewDidLoad. I’m not seeing documentation about this yet, just that I had to use loadView and viewDidLoad to stop some crashing. My creation steps now look like this: