When I posted End of Line: SleepMute for macOS is no longer for sale and removed SleepMute from sale, I didn't expect Apple would be say anything else about it.
Yesterday, Apple sent me this:
 |
| SleepMute on the App Store |
 |
| macOS 15 Sound System Settings |
 |
| App Store Connect email about SleepMute |
 |
App Store Connect App Store Improvement Notice for SleepMuteWhat features were planned for SleepMute 2.0?Mic Mute Hot KeyEver use video conferencing software and while in a meeting, you mute yourself? Then you switch to another window and it's at that exact moment you get asked a question that you should answer quickly Everyone struggles to get back to the window and unmute that app, which wastes everyone's time. All the video conferencing apps do it slightly different too. Wouldn't it be great if macOS had a way mute or unmute the active microphone while in any app? I thought so too and was going to add this so SleepMute. With each macOS release, I expected Apple would add this feature to the menu bar Microphone icon with Standard or Voice Isolation. They haven't yet and thankfully there are some apps in the App Store that do. Jason Snell @ Six Colors wrote that Mic Drop mutes your microphone everwhere. I tried it just today and it's nicely done. You have to trust an app like this because muting a video conference can't fail. I really like the ON AIR icon you can put in the menu bar. Turns out there a lot of these since the last time I searched so take a look. Sound MixerI can't believe macOS 15 still doesn't have a sound mixer. I wanted to do something simple to control the relative volume games to FaceTime or Discord which is a never ending challenge. Struggled with this so much when playing Baldur's Gate 3. Rogue Amoeba has been a leader in macOS sound related apps for as long as I've been using Mac apps. They've got a great app called SoundSource that does a comprehensive job. It's perhaps a tad more complicated than what I had in mind, but there's no denying they have the skills and the business to build a great app. I can't compete with that! App RenameIf I added these features, surely SleepMute would have to be renamed. I was leaning toward Mutetation. Did I accomplish what I wanted with SleepMute?I made SleepMute to stop my Mac from waking up my infant son 14 years ago with random noise when our home iMac shared a room with him. It worked great and did what I needed it to do for a number of years. As he got older and we switched living arrangements, the iMac wasn't in his room. My need for the feature diminished and so did my desire to work on it. Ultimately, that's what I learned. Side projects are usually born from a personal need. Once no longer a concern for you, it's hard to keep driving yourself forward. These days, I'd much rather explore Final Cut Pro to make videos for Travel by Marisa or explore visionOS apps so really that tells me retiring SleepMute is the right decision. |
Tim: Today were announcing three products.This would be the culmination of Tim Cook’s Apple. He’d be 60 years old, just shipped Apple’s most revolutionary product since the iPhone, and with plenty of time to pursue any other projects he wished.
Tim: An Augmented Reality headset
Tim: Vision correcting glasses
Tim: Polarized sunglasses
Tim: …
Tim: Are you getting it yet? This isn’t three products, it’s one.
Tim: I’d like to show you Apple Glass
I’ve already shipped an app that is accessing Face ID on iPhone X, but while testing an unrelated feature the other day, I saw the alert on the left. I thought I had read everything that I needed to about Face ID implementation, but this had slipped past me.
I parked it for a while, but I happened to open the docs on LAContext on an unrelated issue when I saw the Important information on the right.
curl
We would like to acknowledge Dave Murdock of Tangerine Element for their assistance.
That’s from the end of About the security content of macOS Sierra 10.12.6, Security Update 2017-003 El Capitan, and Security Update 2017-003 Yosemite.
I wasn’t aiming to obtain such credit, all I did was File a Radar on curl.
I have no end of trouble downloading Cocoapods, Ruby Gems, Node modules, using Terminal at my day job.
They have a proxy server connected to my Active Directory credentials. For GUI based apps, macOS combined with a little Apple utility called Enterprise Connect configures everything as soon as I make a connection to the network.
However, anything that is strictly command-line is not guaranteed to work.
A bunch of co-workers and I have taken matters into our own hands and written a script that runs in our .bash_profiles. It sets these environment variables when started a shell automagically based on the current username and password:
http_proxy
https_proxy
no_proxy
Both http_proxy and https_proxy have traditionally been set to the same thing, a proxy server like http://proxy.company.com which is only available inside your company. Even the https_proxy variable is configured to hit an unsecured HTTP server.
During an earlier version of the script, I had accidentally set https_proxy to https://proxy.company.com and things were breaking.
Turns out, curl couldn’t support HTTPS proxies until late 2016, and macOS 10.12.5 hadn’t been updated to curl 7.52.0 or later to add support.
So I filed a radar…
Turns out, curl 7.54.0 or later closed a number of CVEs and I mentioned that in my radar.
Fast forward 2 months after I filed the radar, and Apple Product Security emails me to ask if I’d like credit.
I hesitated at first, not knowing what, if any, ramifications being publicly listed on an Apple Security listed might have.
Ultimately, being credited was just to cool not to do, so I did.
While curl has been updated, unfortunately my problems persist. Appears the Generic Security Services Application Program Interface (GSSAPI) somehow occasionally selects the wrong way to present my credentials to the proxy server and I get connection errors.
I’m updating to macOS High Sierra right now hoping that something has changed to resolve this issue, but if not, I’ll be filling another radar.
Though the public Bug Reporter interface recently got a much needed overhaul, the system is still far from perfect.
I’m truly baffled why Apple doesn’t build macOS and iOS apps that developers can use to collect the required information and file with far less work. I bet they’d get a lot more high quality bug reports. I’ve filed a radar on a radar app.
However, I’ve seen enough bugs fixed that I was the original reporter to feel my time is worth spending on filing radars.
While at a Memorial Day gathering yesterday, the host mentioned that an update just became available for his Airport devices, the Express, Extreme, and Time Capsule. I thought he had to have been mistaken and maybe I’d missed updating his hardware on a previous visit. No update had been mentioned in the Apple press, but I knew my AirPort Utility automatic update checking was off, I’d lost hope Apple would ever send out any updates for my aging Time Capsule. Maybe Apple did send out an update…
Sure enough Apple released AirPort Base Station Firmware 7.6.7! The prior version was 7.6.4 released in August 2013. That immediately got my mind racing. Were internal 7.6.5 and 7.6.6 releases created that didn’t make it public? Could more bug fixes be bundled up into this update than just those mentioned in the support article? We’re fixes made during a development cycle for new AirPort Base Stations or to comply with the FCC and back ported to 2 generation old hardware?
I guess we’ll never know, but WWDC is right around the corner, I’m not immune to rampant speculation 😬
You should read it for the entertainment value alone.
In Chris Lattner I Trust!
Is ABI compatibility missing Swift 3.0 annoying? Absolutely.
Is Swift 3.0 source compatibility going to be a time sink with chicken and egg library problems? Yep.
I’m sure dynamism is coming to Swift 3.x or 4 and I’m confident the teams and the community will improve on what Cocoa's had since 1988. Swift is the next 30+ years of Apple developer tooling and platforms. It’s almost insulting to the teams to suggest they aren’t being thoughtful.
Hapuna Matata, because in the coming on 2 years I’ve been using Swift it's saved me so much time with fewer bugs and easier to read code.
| SPOILERS | Ahead for Star Wars The Force Awakens |
|---|
| TL;DR | Don’t assign UITextView.textContainer.layoutManager.delegate to your UIViewController, bad things happen. |
|---|
| Versions: | OS X 10.10, 10.11 | Xcode 7.0.x | iOS SDK 8, 9 |
|---|
Some of the highlight WWDC 2013 sessions for me where those about Text Kit. That was largely because I was working at Dow Jones on The Wall Street Journal and Barron’s iOS apps which had native text layout code. It worked extremely well, but it was largely Core Text, and it wasn’t the easiest to maintain. I thought we might be able to replace a lot with Text Kit. Unfortunately I never got the chance, but I was always curious to try Text Kit’s capabilities.
Fast forward a few years and I got my change this past week. Designers handed me a screen that looks like this:
What I always remembered about Text Kit was the easy way to exclude paths from the layout for things like images and the text could flow around it.
To refresh my memory on how to do that, I did some searching and came across Ray Wenderlich’s Text Kit Tutorial, Updated with Swift. Great, read the article, downloaded the sample, and started using the UIBezierPath calculation stuff in my real project.
That’s where things went off the rails but I didn’t realize it until today. You see the tutorial had this:
let exclusionPath = timeView.curvePathWithOrigin(timeView.center)
textView.textContainer.exclusionPaths = [exclusionPath]
The method curvePathWithOrigin was calculating a round UIBezierPath because the tutorial was inserting a round graphic into the UITextView. I needed to create a rectangular UIBezierPath (see orange box in above image), but didn’t know you could do. Maybe it was the pain from a hand injury, maybe just ignorance or I forgot, but I didn’t get it.
Of course the round bezier path from the tutorial was not flowing text around the rectangle image correctly. It all seems to obvious in hindsight.
I tried many things to fix this issue. One of those was crawling down UITextView’s internal object tree and setting textContainer.layoutManager.delegate to my UIViewController instance. I usually never do things like this but again I probably wasn’t thinking very clearly.
Setting the delegate appeared to make the text flow better because character wrapping became the default, so I left the delegate assignment in. What a mistake!
When I realized how stupid I was being with UIBezierPath and used a rectangular exclusionPath, UITextView was defaulting to character wrapping instead of word wrapping.
Of course I was going through the Six Stages of Debugging:
The Debugging Six Stages #debugging #programming #epic pic.twitter.com/kM6JOG3s5E
— Silviu Ardelean (@silviuardelean)
I finally got to Stage 5 when I built up a sample line by line until I figured out setting the textContainer.layoutManager.delegate to my UIViewController instance was a really dumb idea.
Sometimes when writing code, you make bad choices and it takes a while to figure that out...
iOS 9 is out now and one of the big new features is News and Inner Exception is there!
I didn’t really expect that Apple would take a blog like this into the News pantheon, but they did and it’s live.
Turns out the old logo was so poorly designed by me, it really looked terrible in Apple News, so I made a new one.
Since I look at Menlo all day long in Xcode and this is mostly a coding blog, it seemed like the right choice.
When you have an app for sale and you haven’t logged into iTunes Connect for a while, you don’t often see new features added. The Manage iCloud download settings for this app in the Pricing tab is one such feature that escaped my attention…until now!
Super handy if you need to control this more tightly.
| TL;DR | Annotate the return variable with a type, e.x. let foo:String? = Utility.nullableValueFromKey(“identifier", dictionary: jsonDictionary) |
|---|
| Versions: | OS X 10.10.4 | Xcode 6.4 | iOS SDK 8.4 |
|---|
When I started working with Objective-C coming from .NET, one of language features that I missed the most was Generics. They solve a whole class of problems that are tedious and/or require way more code than without generics. When Swift was announced with Generics...
But Generics can be hard, thinking in T for any giving problem can make you a little crazy, especially when the compiler keeps yelling at you.
In Swift 1.0, I used generic functions to help parsing JSON server responses, the functions worked, but they were less than ideal.
The typical problem I wanted to solve was getting a primitive type out of the response dictionary that could be null.
I ended up with this function to do the trick:
class func originalNullableValue<T>(valueType: T, key: String, dictionary: NSDictionary) -> T? {var value:T? = nilvar valueTemp = dictionary[key] as AnyObject! as? Tif valueTemp != nil {value = valueTemp!}return value}
Ugly! Why did I end up with this? Either I wasn’t smart enough to figure this out or the 1.0 compiler wasn’t.
Getting either me or the compiler to figure out what type T was without passing an argument of that type into the method, was, well let’s just say it was the solution I found.
What I wanted was this:
class func nullableValueFromKey<T>(key: String, dictionary: NSDictionary) -> T? {var value:T? = nilvar valueTemp = dictionary[key] as AnyObject! as? Tif valueTemp != nil {value = valueTemp!}return value}
So I dusted off the original method and tried making it what I wanted with Xcode 6.4 & Swift 1.2.
Defining it works fine, but If you attempt to call it:
let foo = JSONUtility.nullableArrayFromKey("fooBar", json: Dictionary<String, AnyObject>())
The compiler returns this error:
I have no way to know/test if this is the same error that caused me trouble in Swift 1.0, but this time, either I or the compiler were smart enough to figure it out!
All you have to do is add the type to the variable declaration:
let bar:String? = JSONUtility.nullableValueFromKey("name", dictionary: Dictionary<String, AnyObject>())
I nearly burst from laughter after reading this tweet and then article by Dan Gillmor:
New Android vulnerability + industry fecklessness = need for new laws/regs. My latest at @slate@FutureTenseNow: http://t.co/uzPgEJZYgD
— Dan Gillmor (@dangillmor)
What’s so funny? The free market is working in this case exactly as intended. A company in the market, e.x Apple, provides mobile devices that are usually secure and updated. Some consumers have voted with their dollars that isn’t as important to them as other criteria, so they bought an Android phone. There is no surprise here that if you buy an Android device, you highly likely will not get updates of any kind, security or otherwise.
What criteria stops people from buying an Apple device? Let’s return to Mr. Gillmor:
Apple's iOS devices, of course, are part of a tightly controlled ecosystem, and while Apple is far from perfect on security, it does update iPhones. But we shouldn't be required to turn over our computing and communications to control-freak companies in order to get necessary security updates.
So let me get this straight? Mr. Gillmor doesn’t want Apple devices because Apple is a “control-freak” company, so he invites the control-freak government to use laws & regulations & force Android implementors to be more control freaks about updates…like Apple. LOL. Sure, the government is always the lightest touch!
If Android users thought updates and security where higher priorities than cheap phones or “open source” software, then they wouldn’t have bought an Android device.
Returning this as not a bug, working as intended!
Epilogue
Google made this mess, they can still fix it. They already offer an Android Bug Bounty. They have a generic Patch Reward Program.
Instead of the heavy hand of laws and regulations, Google should start an Update Rewards program.
Every carrier or vendor that releases Android updates in a timely fashion (say within 1 month) gets a payment from Google.
Security Updates pay more than Feature Updates. To really sweeten the pot, Google can pay per user upgraded, get some vendor/carrier incentive to update as many users as possible.
Vendors/carriers have such thin margins, seems like they don’t have the money to cover testing and deploying Android updates without taking a loss.
Use some of that ad revenue to cover the costs. I mean, advertisers should be clamoring for this. After all, how can they trust the ad profiles Google vends with compromised devices?
| TL;DR |
overridefunc viewDidLoad() { super.viewDidLoad()
self.tableView.separatorInset = UIEdgeInsetsZero self.tableView.layoutMargins = UIEdgeInsetsZero }
override func tableView(tableView: UITableView, willDisplayCell cell: UITableViewCell, forRowAtIndexPath indexPath: NSIndexPath) { cell.layoutMargins = UIEdgeInsetsZero } |
|---|
| Versions: | OS X 10.10.4 | Xcode 6.4 | iOS SDK 8.4 |
|---|
Almost every iOS app has at least one and usually more UITableViews and associated UIViewController or UITableViewControllers to manage them.
The view’s ubiquity has to make implementing it very tough and I don’t envy the team that has to account for all the use cases.
Over time, UITableView, UITableViewDelegate, UITableViewDataSource, and UITableViewCell have become very large. Throw in their subclasses, UIScrollView & UIView, and developers have to remember a lot of stuff to get all the behavior they want.
Or in this case, don’t want. UITableView enforces default layout margins and separator margins that are not obvious…once you use AutoLayout.
This is what you see in your storyboard:
This is what you see in the app:
Notice the left hand margin? There is no option you can change in the Storyboard to fix it, you just get an indent/margin/inset you didn’t ask for. The storyboard doesn’t show this, so I’m not sure if this is a bug in the Storyboard editor, or in runtime in UITableView.
What’s happened is that I added a few AutoLayout constraints to the left red bar (margins t: -8, l: -8, b: -9).
When I do this, the tableView.layoutMargins appear to be their default value of 8. It looks like without AutoLayout, UITableView resets layoutMargins to UIEdgeInsetsZero, but with AutoLayout, it either wants the default margins or there’s a bug.
You have to add the following code to fix the pre-cell tableView display:
override func viewDidLoad() {
super.viewDidLoad()
self.tableView.separatorInset = UIEdgeInsetsZero
self.tableView.layoutMargins = UIEdgeInsetsZero
}
But that’s not enough to get the cells looking right. Based in part on this StackOverflow post, but with my own testing, you have to implement the delegate callback willDisplayCell like this:
override func tableView(tableView: UITableView, willDisplayCell cell: UITableViewCell, forRowAtIndexPath indexPath: NSIndexPath) {
cell.layoutMargins = UIEdgeInsetsZero
}
Why do we have to set layoutMargins again in willDisplayCell? Apparently the cell’s layoutMargins get reset again right UITableView decides where to draw the separator line, so you have to make them whatever you want. Curiously, willDisplayCell has existed since iOS 2, but I don’t remember needing to use it before iOS 8.
Now we get what we want.
Another Workaround That’s Incomplete...
This other StackOverflow post mentions the UIView property preservesSuperviewLayoutMargins. It defaults to NO/false, but for a UITableViewCell is set to YES/true.
You could have mostly solved the problem by explicitly setting that property to NO/false, but it would not have fixed the separator issue.
iOS 9 Beta
I haven’t run through this on iOS 9 beta, so I don’t know what the the default indent situation is there.
| TL;DR | Look at the File Inspector tab (the one with the blank document) of your storyboard |
|---|
Whenever I go looking for the Global Tint defined in the main storyboard in Xcode, there’s always a moment of cognitive dissonance.
My problem is that I go looking for some kind of Window object, which of course is how you’d do it programmatically (in Swift):
UIApplication.sharedApplication().delegate?.window!!.tintColor = UIColor.redColor()
The double !! after window is not a typo according to Xcode, though it sure looks weird.
Anyway, I guess nobody wants to make UIWindows things in Storyboards, so this property is stashed under the File Inspector tab!
All about fighting malware extensions. Not just on Windows stable, but Windows dev and all OS X soon.
Open Always Wins!
| TL;DR | Use standard "Import Framework" in Swift instead of the Obj-C bridging header for Obj-C Cocoapods with use_frameworks! in your Pods file |
|---|
| Versions: | OS X 10.10.3 | Xcode 6.3.1 | iOS SDK 8.3 | Cocoapods 0.36.1 |
|---|
This just wasn't obvious at all. I've been using Swift & Cocoapods < 0.36 since Xcode 6 shipped. While versions < 0.36 did not work with a Swift framework like Alamofire, you could use Objective-C pods and let them get compiled as a static library as long as you used the Objective-C bridging header to import the header(s).
With Cocoapods 0.36 and above, you can have Swift frameworks as Pods. To make that work, you have to put the use_frameworks! keyword in your Pods file. My brain misunderstood Use frameworks instead of static libraries for Pods because it automatically inserted for Swift before the Pods in that sentence.
Took me a couple hours this morning to work out all my Pods might be framworks. I'm not the first person to figure it out, just a few days ago, Johannes Luderschmidt published a blog post with the solution which put on the right path. All Pods using use_frameworks! are frameworks, not just the Swift pods. A problem like this is where experience with Xcode can really work against you. You start tweaking Header Search Paths, Framework Search Paths, User Header Search Paths, and the Always Search User Paths (docs: disabling it is strongly recommended) settings in desperation because that's usually where these problems lie. Especially when the first compiler error in your project after putting use_frameworks! in your Pod file is that the header for come Objective-C pod can’t be found.
But that’s totally down the wrong rabbit hole. I’m using the Obj-C MBProgressHUD Pod. What you need to do is:
You're now using bona fide frameworks, so your enums have moved in flight! You might have a line of Swift that was fine with the bridging header like this:
progressHUD.mode = MBProgressHUDModeIndeterminate
That now has to become this:
progressHUD.mode = MBProgressHUDMode.Indeterminate
Not to big a deal, but the pile of errors might lead you astray that you have a bigger problem than you do if you’re using a lot of Obj-C enums.
