Archive for 'iPhone'

SpriteBuilder 1.3

Just in case you haven’t been keeping track of developments over in the Cocos2D-Swift (née cocos2d-iphone) world, you might want to take a look at how SpriteBuilder is continuing to shape up right nicely into a — nay, the — friendly cross-platform development environment:

SpriteBuilder 1.3 Beta

In this beta, you’ll get early access to exciting new features we’re working on for the 1.3 full release, including:

  • The all-new Cocos2D Metal renderer for iOS 8 (and compatible devices)
  • CCEffects UI – add and edit amazing effects in SpriteBuilder with a few clicks!
  • Packages in Cocos2D – load groups of resources dynamically in your game!
  • An improved OpenGL renderer with multithreading option
  • Other iOS 8 optimizations and bug fixes

And, last but not least… the SpriteBuilder Android Plugin, now in public beta!

The what?

The SpriteBuilder Android Plugin extends the Cocos2D game-building power of SpriteBuilder to both iOS and Android. The SpriteBuilder Android Plugin uses clang to cross-compile Objective-C to native ARM and x86 machine code – no virtual machines, emulators, or Java translation. Your app will run faster than a Java-equivalent Android application. Additionally, since you have full access to every iOS and Android API, you maintain complete control over how your application is built. The SpriteBuilder Android Plugin allows you to expand your game’s audience while still using the Xcode environment you are familiar with…

Last few months we’ve been picking away at getting an old school cocos2d game with heavy UIKit overlays up to speed with the apportable library. Our conclusion was that why yes once upgraded to Cocos2D-Swift 3.x the Cocos2D bits went quite impressively smoothly; the UIKit stuff … well, mostly there. With just enough not in that mostly to cut the experience down somewhat from unqualified success. Looks like our experiences there are not terribly unusual, as it seems like Apportable is doubling down on what they do well here and scaling back on the everything to everybody idea. Best of luck to ‘em!

Continue Reading →
0

Apple-Paying The Piper

So between squeeing over the watches and squealing over the bendy phones and free music and all the other nonsense that just seems to get sillier all the time, anybody remember that other little thing Apple squeezed into their do? Haven’t seen very much discussion of that yet, but we’re kinda suspecting here it might turn out to be more of a Big Deal than most people are expecting right now. Here’s an excellent article to catch you up if you’ve been in the distracted by the shiny things crowd:

How Apple Pay works and why it matters for developers

Background: Clover and First Data (our parent company) have been working with Apple to prepare for the launch of Apple Pay to support developers, merchant acquirers, and issuing banks (see First Data’s press release). Clover is enabling all merchants to accept In-App payments, and will be In-Person/NFC enabling all merchants as well (see https://www.clover.com/features/iphone). Here’s a bit of how it works from a developer’s perspective, and why it matters…

Apple Pay marks the first time a popular operating system is making payments a platform service for real-world, non-digital-good transactions, in a broad, inclusive manner that is compatible with the mainstream payments processing industry. At Clover we’re particularly excited because we believe it opens up lightweight apps that can interact and transact with small-and-medium brick-and-mortar restaurants. By lightweight, I mean that these apps won’t need to maintain a user database, require user logins, worry about getting cards on file, or being an unwilling payment aggregator. i.e., it will be at least 10x easier. I expect a huge amount of innovation in real-world mobile commerce as a result over the coming years because of the revolution that Apple Pay is starting…

Generally we tend to dive headlong into Full On Mockery Mode™ soon as we see “revolution” touted in this industry, as perhaps the Dear Longtime Reader may have noticed here and there; but yeah, in this particular case, ok, this just could turn out enough of a thing that “revolution” would only be mild hyperbole. If the details are a bit eye-glazing to you, we’ll tl;dr here from the comments:

This article does explain the advantage Apple Pay has over other eWallet systems. By utilizing Network-Level Tokenization, Apple has integrated with all gateways, processors, issuers, and acquirers in the current payment scheme by negotiating directly with Visa, MasterCard, AMEX, Bank of America, JP Morgan Chase, Wells Fargo, and the list goes on…

This isn’t something that other eWallets have done. Thus, why Apple Pay will be around… and others won’t.

We’re pretty firmly on board with that prognostication.

There’s some more perspectives worth reading collected over at Michael Tsai’s blog.

UPDATES:

“Starting today, any Stripe user can begin accepting Apple Pay in their iOS apps.”

Continue Reading →
0

iPhone 6 Screen Apoplexia

Starting to feel like you’re totally losing the plot now that your iOS app can find itself living in five different point dimensions,

  • 320 x 480
  • 320 x 568
  • 375 x 667
  • 414 x 736
  • 768 x 1024

and three different point scales,

  • @1x: up to iPhone 3GS/iPod 3G/iPad 2/iPad mini 1
  • @2x: everything later except
  • @3x: iPhone 6 Plus

and even a logical to physical downsampling discrepancy on top of that? Here, go check this out to explain it:

iPhone 6 Screens Demystified

To demonstrate different rendering of pixels on various devices, we compare how 1-point wide line is rendered on

Original iPhone – without retina display. Scaling factor is 1.

iPhone 5 – with Retina display, scaling factor is 2.

iPhone 6 Plus – with Retina display HD. Scaling factor is 3 and the image is afterwards downscaled from rendered 2208 × 1242 pixels to 1920 × 1080 pixels.

The downscaling ratio is 1920 / 2208 = 1080 / 1242 = 20 / 23. That means every 23 pixels from the original render have to be mapped to 20 physical pixels. In other words the image is scaled down to approximately 87% of its original size…

TL;DR: If you haven’t yet … it’s time to buy PaintCode!

UPDATES:

Using Vector Images in Xcode 6

Xcode 6: Live Rendering, Visual View Debugging, and Swift

Responsive iOS Buttons with PaintCode

Adaptive Layouts For iPhone 6

How to design for thumbs in the Era of Huge Screens

Adaptive user interfaces

What iOS 8 Means for App Design

What’s our Vector, Victor?

iPhone 6 Plus Pixel Peeping

Continue Reading →
2

Tip: Xcode 6 Bundle Signing

Having this problem with your shiny new Xcode 6 GM?

Screen Shot 2014-09-10 at 8.12.00 AM.png

Problem also discussed here.

Solution 1:

Adding the `–deep` flag to “Other Code Signing Flags” (OTHER_CODE_SIGN_FLAGS) got me around this.

Solution 2:

Delete Info.plist inside the bundle if it’s only a resource package.

(And if there’s some reason you need it, at least delete the ‘CFBundleExecutable’ key.)

Good luck with that!

Continue Reading →
0

Layout Best Practices

Read of the day while you’re nervously waiting to see what will need panic rewrites tomorrow:

Screen Shot 2014-09-08 at 8.33.11 AM.png

Don’t think there’s anything in there actually covered by NDA at this point, but we’ll just refer you there for the beta software feature discussion bits. The important parts are not new, but they’ve been widely disregarded to date, at least they sure are in software we get stuck maintaining:

  • Nowhere should you be using screen or window size to do layout. Your view bounds should be the only consideration.
  • At load time, as called out above, you’re not in a hierarchy yet. Therefore you do not know what your view bounds will be. This has always been a thing for any view contained by a view with its own layout, and became more of a thing with iOS 7 when your views developed an inclination to jump under the status bar behind your back, but rumour has it that it will be a big thing very soon.
  • layoutSubviews is the best place to be putting your legacy-type frame setting code.
  • updateViewConstraints is the correct place to figure out your interface for reals; if you’ve so far avoided auto layout, now is a superb time to get on that.

Hopefully none of this is any particular news to you, so getting all those legacy codebases copacetic with whatever novel execution environments actually appear tomorrow from the collection of swirling rumours should be no problem, right?

Continue Reading →
0

Standards Marked Downer

Here’s an interesting case study on how to not make friends:

Standard Flavored Markdown

It took a while, but I’m pleased to announce that Standard Markdown is now finally ready for public review.

standardmarkdown.com

It’s a spec, including embedded examples, and implementations in portable C and JavaScript. We strived mightily to stay true to the spirit of Markdown in writing it. The primary author, John MacFarlane, explains in the introduction to the spec

Well, that all sounds well and good, aside from having a snicker at the obligatory xkcd 927 mention, doesn’t it? Um, no. After not too many yay! great! finally! comments on the above, we start getting

… We all use Markdown, not just you and your pals. It isn’t yours to do with as you please. Create something new, and respect prior art…

… Besides that, the hubris involved in calling your fork standard is a bit much…

… any such effort needs to do so under a new name. Not to do so is confusing to users and needlessly hostile toward John Gruber…

… Ignoring this term means you’ve broken the deal, and opens you up to a copyright infringement lawsuit…

Oops. The comments devolve from that last point into wrangling over the legal definition of ‘derivative’ … but if you’re down to arguing on that level, well, you’ve already lost, haven’t you?

Screen Shot 2014-09-05 at 2.59.35 PM.png

… yeah, that’s a pretty darn good example of exactly the kind of reaction you want your new project to avoid at all costs.

Now, we generally try to actively avoid pointless drama like this — what led us to this donnybrook was actually a handy looking new pod

laptobbe/TSMarkdownParser

TSMarkdownParser is a markdown to NSAttributedString parser for iOS implemented using NSRegularExpressions. It supports many of the standard tags layed out by John Gruber on his site Daring Fireball. It is also very extendable via Regular Expressions making it easy to add your own custom tags or a totally different parsing syntax if you like…

which looked like a particularly nicely lightweight way to manage some easy attribution of strings. ‘Course, there’s lots of other implementations around too, if that particular one isn’t adequate to your needs. Or you could always start your own flavour. “Definitive Markdown”? “Authoritative Markdown”? Those aren’t taken yet!

UPDATES:

And the first attempt was to try “Common Markdown” and that didn’t work either … so now it’s CommonMark!

Continue Reading →
0

Tip: Open Settings URL

Oops, we managed to miss this in the WWDC videos:

Open Settings URL

A quick tip I picked up from WWDC 2014 session 715 on User Privacy. Starting with iOS 8 there is now a settings launch URL to send the user directly to the settings for an App. The code snippet below will do the trick:

[[UIApplication sharedApplication] openURL:[NSURL URLWithString:
UIApplicationOpenSettingsURLString]];

If you’ve got any functionality that the user can say no to, it’s guaranteed they will, and then they’ll send you angry letters and one-star reviews when it doesn’t work, you’ve all been there right? So make sure you put on your iOS 8 upgrade checklist putting in a helpful remediation option wherever deniable things can fail!

Continue Reading →
0

Storyboard Launch Images

So, you been fearing what the likely new @3x sizes are going to do to your seven and counting launch image requirements?

Well, looks like all that fuss may be going away soon:

Replacing Launch Images with Storyboards

An Interface Builder-Based Launch Screen

In Xcode 6, there is another option. You can specify a storyboard whose initial view controller will then be used as the appʼs launch screen. This is how:

  1. Create a blank storyboard file named LaunchScreen.storyboard.
  2. Go to your target settings and, on the General tab, select the storyboard as your Launch Screen File. Xcode will add a corresponding UILaunchStoryboardName key to your appʼs Info.plist. When this key is present, Xcode will prioritize it over any launch images you might have set.
  3. Add a view controller scene to the storyboard. Add some subviews to the scene and position them with constraints. When you launch the app on a device, the OS should use the scene as the launch screen.

One Storyboard for All Screen Sizes

You can use the new adaptive UI features in Interface Builder to fit your layout to different screen sizes. If your scene requires screen-size-specific images, use asset catalogs to define different images per size class. Note that you can not only adjust constraints for different size classes, you can also remove selected views from a specific size class entirely by deselecting the Installed check box. See WWDC session 411 for details.

Also Works with NIBs

Despite the name of the UILaunchStoryboardName key, this also seems to work with NIB/XIB files containing a single view. When you open such a XIB file in Xcode, the File Inspector displays a check box named Use as Launch Screen, which is not there for storyboards…

There’s a number of partially-implemented caveats at the moment, but looks like a solid reason to get up to speed on those new adaptive UI features, because as they say

Screen Shot 2014-08-30 at 9.00.52 PM.png

Speaking of which, here’s a handy UICustomResolutions extension for UIWindow to help testing that!

h/t: iOS Dev Weekly!

UPDATES:

Yup, it’s 667×375@2x(1334×750) and 414×736@3x(2208×1242) just as predicted, and new @3x icon sizes to match!

As for xib/storyboards, they’re required for the new devices:

You use a launch XIB or storyboard file to indicate that your app runs on iPhone 6 Plus or iPhone 6.

Oh, wait no: You can also add raster images to the new LaunchImage.xcassets buckets.

Continue Reading →
0

Affilate API: Uber

Got an app with a map? This might be of interest to you:

Introducing The Uber API

As of today, we officially open—to all developers—access to many of the primitives that power Uber’s magical experience. Apps can pass a destination address to the Uber app, display pickup times, provide fare estimates, access trip history and more.

Note that ‘more’ does not currently include ‘actually call for a ride or anything’ though,

What about requesting a ride? Yes, we’ve implemented that endpoint as well, but because calling it immediately dispatches a real driver in the real world, we’re releasing it in a more controlled fashion, starting with a small set of partners. Stay tuned for more on that, and please let us know if you’re interested in being added to the whitelist.

OK then. So what’s in this new Affiliate Program for us exactly?

  • Offer your users credit toward their first Uber ride when they sign up via your app
  • Earn $5 (USD) in Uber credit for every new rider
  • Receive credits that never expire in your Uber account every month
  • Build something amazing and get your app featured on our site

Gotcha. Free rides! That’s awesome! Oh, no, wait … no it’s not. Not if you hang in Most Livable City #3:

Uber Has Expanded to 130 Cities, Vancouver Remains Only One It’s Ever Had to Back Away From

Oh, wait more … no, it’s really not.

This program is currently available to developers in the US only.

Well, that’s not rocketing up our priority list then. But hey, if you are a U.S. developer with a map-using app, something you probably want to consider!

Continue Reading →
0

Airship Pushing Us Overboard

So it’s been a seriously long time since we looked at APNS providing options, as it’s been the universal default for everyone we’ve worked with since to default to Urban Airship. And, generally, to be perfectly satisfied with their free level of service. Turns out they’ve had enough of us freeloaders:

We’ve discovered that we work best when we’re working closely with our customers to help them solve their problems and implement a mobile-first experience for their users with our complete solution. [Ed. - why, what a polite way to say “getting paid”!] Today, we’re taking some concrete steps toward crystallizing that focus by sunsetting our free Developer Edition product that offers a subset of the capabilities of our complete solution.

If you are using the Developer Edition offering, everything will remain the same for the next six-months until its retirement on December 31, 2014. Between now and then, Developer Edition users can either choose to establish a paid relationship with Urban Airship for access to our push-only product or our full solution suite, or migrate to an alternate solution…

Well, these days when less than half opt in to pushes at all, it’s pretty hard to make a case for that for most of our Airship usage. So let’s see what options there are in the “migrate to an alternate solution” space for the freeloading indie, shall we?

In the messaging-focused provider category:

Appoxeestarts at $500/month

Boxcar — 200 pushes per minute to 100 devices for free; goes up by ppm

Element Wave — unlimited to 5K users for free; trial-only for more

Moblico — trial accounts only

Push IO — trial accounts only

PushApps — 1M pushes to 100K devices from 5 apps for free; notably cheap unlimited plans

PushWizard — 30 messages to one app on unlimited devices for free; smorgasbord of paid additions

PushWoosh — unlimited pushes to 1M devices from 5 apps for free; tiered paid feature sets

TheAppSales — “a good size number” for free

XtremePush — unlimited pushes to 1M devices from 5 apps for free; tiered paid feature sets

In the cloud service space that provide messaging on the side:

Amazon SNS — 1M pushes for free; then $1/1M pushes

App42 — 1M pushes for free; tiered price plans

Asking Point — 3M pushes for free; pay via commission

Kinvey — 5M pushes for free; tiered price plans

mobDB — 600K pushes for free; then $15/1M pushes

Parse — 1M pushes for free; then 5¢/1K pushes

If there isn’t something there that suits your feature vs. price requirements adequately, there’s always rolling your own: By far the most popular on github, which we’ll take as sufficient proof of adequacy and not bother looking further, is

Redth/PushSharp: “A server-side library for sending Push Notifications to iOS (iPhone/iPad APNS), OSX (APNS 10.8+) Android (C2DM and GCM – Google Cloud Message), Chrome (GCM) Windows Phone, Windows 8, Blackberry (PAP), and Amazon (ADM) devices!”

but if you want more choice, hey there’s 412 following it thrown up for APNS on Github, go wild.

One last special mention of noodlewerk/NWPusher that lets you do your development with a local OS X application, which certainly would have expedited many of our past projects.

Think we managed to catch all the services currently worthy of short list consideration here; if we missed stumbling over your favourite, of If you have any positive or negative experiences with any of these to share, please do!

Continue Reading →
4
Page 2 of 99 12345...»