In June we announced that we had begun a private BETA of Airship Commander. Several of our clients had also began to use the app internally to push notifications to users of their apps. Today we are happy to announce that we submitted version 1.0 to Apple for approval.
That was an easy Radar for me to file. It’s not a bug, but it is bugging me nevertheless.
I am disturbed by the disparity between the NSShadowAttributeName attribute (which can only hold a single NSShadow) and CSS where you can have multiple shadows. Because NSHTMLWriter simply copies these to the CSS style of a span it should be quite easy to to also let NSHTMLWriter take an array.
It’s not a very important feature to have, but hey … it would give me some peace of mind. 😉
Filed as Radar#12908144.
While researching the root cause for the UITextView line-height bug I also found another difference between attributed strings rendered via CoreText and UITextView. The latter ignores font kerning.
UITextView uses Webkit for displaying attributed strings. Unfortunately Kerning is disabled on Webkit views unless you specify a certain CSS style.
If you look at the AV characters you can see how the version with Kerning enabled has the AV seem at a more natural distance while the lower line has an uncomfortably wide distance between them.
In the Radar (which I filed under #12889869) I argue that when setting text on UITextView via setAttributedString we developers expect for Kerning to be on by default since this is the way that is closest to how CoreText renders it.
I had begun development on DTRichTextEditor a few months before WWDC 2012. This was the time when Apple announced that UIKit would support attributed strings beginning with iOS 6. 3 classes to be exact – if you search the documentation for the attributedText property – UILabel, UITextField and UITextView.
Back then I I was hesitant to concede that Apple had sherlocked my open source work in DTCoreText. Yes, there where a few formatting styles now supported, but still the initWithHTML which exists on Mac was still nowhere to be seen on iOS. In the least people would still be able to bridge the gap from HTML to NSAttributedString with my classes.
As I dove more into making DTCoreText compatible with new attributes used by iOS 6 I found the approach that Apple chose to take quite limited and extremely incomplete.
Recently I’ve been getting more and more requests from potential clients to show them the license that is attached to components they would purchase from my parts store. I didn’t have any except some verbal description.
On open source software I now routinely add a 2-clause BSD license, so it was about time to also get a proper license for my commercial components.
Here’s the license I am going to use from now on. I adapted it from the commercial Development License that Peter Steinberger uses on his PSPDFKit, with a few modifications. Peter only allows use for a single app, our components can be used in all apps published via the licensee’s app store account.
So if you develop apps for yourself then you just need to purchase one license for all your apps. If you develop an app for somebody else then this third party has to obtain a license (or you have to obtain it in their name). You can also purchase an Extended License upgrade that lifts this restriction.
This license also adds permission for me to mention your company on Cocoanetics.com. It also now allows for providing modified versions of the component source code to third parties, provided that those are also holders of a separate license.
If you are an existing license holder for any of our things then it won’t hurt if you get in touch with us and see if your licensing is still ok for your specific use case.
I’m working on making DTCoreText iOS 6 compatible and when implementing line heights I found this problem. Naturally I filed a radar.
This is one of many shortcomings of UIKit’s support for attributed strings. A workaround for this was described as having to omit font attributes from the attributed string. So you can either have multiple fonts and unchanging line height or only the font you set on the font property of UITextView.
Other people are having the same problem, as outlined by this question on StackOverflow.
Filed as rdar://12863734
I received a spreadsheet from our accountant that totals our company revenues over the various categories of income that we receive. I figured, why not share this with you? I won’t tell you the absolute numbers, but I think the relative distribution might be interesting.
19 months ago I wrote about the various kinds of income an iOS development outfit can have, when I was basically still in the discovery phase. Taking a long hard look at the distribution over those categories should yield some insights as to how to tweak the amount of effort you put into the various items.
It’s been a while since the unveiling of the iPad mini and new new Retina iPad (aka iPad 4). I like to compare image decompression performance between device generations because personally I believe that this tells a more tangible story than any other benchmark where you end up with some score.
We were told that iPad 4 would be twice as fast as the iPad 3 and that the iPad mini would be at the same performance level as the iPad 2. So we shall compare the results for these devices to see if these statements hold. Also we would like to know if there is any sort of tangible benefit from including armv7s code in our apps.
I am so angry right now. It is taking a lot of restraint to not be resorting to swear words about this one well-known corporation. Trust me, every time I have to cancel an invoice for a component from my Parts Store I am contemplating creating a black list page on my site. Those would be the companies to not do business with.
But I never carry this through. I don’t like to burn bridges. At least not fully.
That’s certainly a mouth full. We stumbled on this weirdness when working on PDF Importing for our iCatalog Editor. I am filing this as a Mac bug at the same time as communicating with DTS to see if they can offer a workaround for this problem.
The problem appears if a PDF is using a CMYK color blending space on a page for transparency blending. That causes this effect. Left side is how the PDF comes out on Mac, right side how it looks correctly on iOS (Simulator/Device). Also if you view the PDF in Preview or Pixelmator it looks weird, only in Adobe’s tools do they look correct.
If the behavior were the same on Mac and iOS then I would have thought to be Adobe using some weird special extension, but since the output is correct on iOS we think that this must actually be a bug. Maybe the Mac version of Quartz PDF rendering tries to do something smart since it is aware of color calibration but doing so messes up the colors.