Gizmodo: “On July 7, four thieves reportedly nabbed over $27,000 in iPhones and MacBooks from the Fashion Fair Apple Store in Fresno, California. Surveillance footage of the robbery shows the men hurriedly entering the store, walking up to display tables, and grabbing a bunch of devices as customers and employees stare on with placid astonishment.”
Sigh. This just had to happen in Fresno, didn’t it?
Why doesn’t Apple improve on the iPod Touch every couple years? Why not take older chip sets — maybe a model from last years iPhone — and leave the form factor alone? Just keep stuffing updated tech into the existing design.
There are folks that can’t afford to buy their kids an iPhone but the iPod Touch may fit nicely into their budget.
As a developer this is also a nice machine for testing. The only issue I see is it hasn’t been revved in a long time. It’s still using an A8 processor but it is still slightly ahead of the iPhone 5s which uses an A7. that’s important because the iPhone 5s is the lowest end iPhone that supports iOS 12. That means we could get another couple years use out of the current generation iPod Touch.
The iPod Touch with 128GB of storage sells for $299US.
Becky Hansmeyer: “For instance, I can take just about any Objective-C code and do a word-by-word translation to Swift that will compile and run, but it won’t be very “Swifty.””
The notion of being Swifty kind of bugs me. If you work in a language long enough you’ll naturally gravitate to language conventions or you won’t. If you’re an Indie, like Becky, I don’t think it really matters how Swifty your code really is. What matters is you’re willing to learn and adapt with the times and you can ship. If you don’t ship you don’t get paid.
I’m probably not very Swifty either, but I don’t really care. I can write code in Swift and it works just fine. During code review with my peers they’ll let me know of a more Swifty way of doing things so I can either make a change or get it the next time. I’m willing to do the new thing and I think that’s what we need to be willing to do if we’re going to survive as developers.
Be ready for change and adapt. That doesn’t mean you have to do it all on day one. Just be willing to make the change.
I’d mentioned a few weeks ago that I was moving to Hugo. The motivation for me was simple. I’d not made my self-hosted WordPress blog secure enough so a not very nice person got into it and did mean things. I was not pleased.
Some of you may be asking yourself, why not fix it and keep using WordPress. Good question. Basically I’ve done that twice now. This time around required deleting my installation and reinstalling. It worked out quite well and I decided not to install a number of plug-ins I’d been using before, including Jetpack. My weblog is actually quite a bit faster now as a result.
So, back to the move. I’m moving to Hugo but I’m still trying to figure out some mysteries of Hugo — at least they’re mysteries to me. I’d like a ‘dirty’ directory structure and I want to make double-sure when I create a post the archive of the post shows up in its proper location, like this:
That is super important to me. All of my current WordPress posts, like this one, have that structure. My plan is to import all of my WordPress posts into my new Hugo site, so it needs to be backward compatible.
Anywho. Here’s how I plan to configure my weblog.
Use GitHub for storage – Posts will be edited locally as Markdown and pushed to GitHub.
Use GitHub for publishing – Once a post is pushed to GitHub it will cause a GitHub server trigger to run. That will pull the source on my host.
Run Hugo on the host – Hugo will live on my host and will be run when the GitHub server trigger executes.
Using those steps should allow me to easily update anywhere I can pull code from my GitHub account — even on iOS — and push changes. For now I plan on using BBEdit on my Mac for writing but in the future I hope to use my own Blogging Tool.
If anyone notices a flaw in that logic please get in touch. My email address is firstname.lastname@example.org.
Quora: “Total cost for creating Tinder-like app for one platform would be about $5k – $10K.”
Charging $5-10$K for a Tinder-like application is how you go out of business. I’m speaking from experience here.
Back in 2014 I made my second run at freelancing. This time around I failed. I learned a lot about who I am and how not to run a business. Two of the primary reasons were charging too little for my work and not being a blazing fast coder.
I’m going to step out on a limb here and park a Tinder-like app — a service really — at around $100,000.00, not 10. Call me crazy, it’s fine. Let’s take a look at some estimates given by folks that have actually built some great software.
First up, Craig Hockenberry: “With such a short schedule, we worked some pretty long hours. Let’s be conservative and say it’s 10 hours per day for 6 days a week. That 60 hours for 9 weeks gives us 540 hours. With two developers, that’s pretty close to 1,100 hours. Our rate for clients is $150 per hour giving $165,000 just for new code. Remember also that we were reusing a bunch existing code: I’m going to lowball the value of that code at $35,000 giving a total development cost of $200,000.“
Emphasis is mine.
In the same Stack Overflow post we find Jonathan Wight weighing in on the cost for the Barack Obama App: “The Barack Obama app took 22 days to develop from first code to release. Three developers (although not all of them were full time). 10 people total. Figure 500-1000 man hours. Contracting rates are $100-150/hr. Figure $50,000-$150,000. Compare your app to Obama.app and scale accordingly.”
Both of these guys are world class software engineers. I have no reason to doubt their estimates because they have the experience needed to build any application.
Here’s Kyle Richter of the excellent Martian Craft: “In February 2013, the average cost of a house in the US was $152,000. By our estimates inside of MartianCraft, the average cost of an app is approximately $120,000.“
If you want a high quality application be prepared to pay for it. Sure, you might be able to get your Tinder-like experience for $5-10K, but it may behave and scale like a $5-10K application and service.
Know what you want and what you’re getting into before you talk to developers about building your dream application or service.
Harry McCracken: “And for close to seven years, I’ve used an iPad in a keyboard case as my primary computing device. In all the years that I’ve been raising my arm to the screen to tap icons, scroll through text, and perform other actions, it’s never felt like an ergonomic burden, or even something I give much thought to one way or another. There are certainly instances when using a mouse or trackpad might have felt easier—for selecting large chunks of text, for instance—but that has less to do with inherent problems with touchscreen computing than it does the design of iOS and iOS apps.”
I like to visit a local Starbucks when I’d like to get out of the house while working. When I do I have a habit of counting the devices I see around me and what type they are. Are they MacBook’s are they PC’s? I’ve run across a fair number of folks using touchscreen Windows boxes, most notably Surface Pro’s. They’re great computers. The display is basically a tablet with a detachable keyboard. Think about iPad Pro with an Apple Keyboard. Yeah, just like that, but in this case the computer is running full blown Windows. I know it’s blasphemy to you like Windows in the Apple ecosystem, but I really do like the Windows Operating system and Microsoft’s developer tools. They’re both top notch. If I were writing Windows applications everyday I’d pick up a Surface Pro as my daily driver. It would be powerful enough for building code and I could detach the keyboard and use it as a tablet. Oh, did I mention the Surface Pro has a pointing device? That’s a big bonus for fine grained selection.
In conclusion you can lump me with the “I’d love to see a MacBook Pro with touchscreen or a new product based on iOS that is deeper, richer, than ever before” crowd. A version of iOS with a trackpad and mouse pointer that can run Xcode — optimized for iOS — and other tools.
Six Colors: “Now, a new report suggests that Apple may once again veer into color territory, with the current metallic options joined by different shades, including blue and orange. Frankly, it’s about time.”
If Apple drops an orange MacBook Pro on the market, oh my. Take my money, as long as the keyboard works.
a sweet, yellowish paste of ground almonds, sugar, and egg whites, often colored and used to make small cakes or confections or as an icing for larger cakes.
a new Apple Framework for building Mac and iOS Apps from the same source code.
A unified Apple Framework makes sense. By this time AppKit is fairly old, it began life at NeXT and moved forward as Apple’s new framework on macOS. When Apple created iOS it made sense to reconsider the user interface and user experience for a touch based interface. Having support for mouse clicks and menus didn’t make a lot of sense for something so small controlled with your finger. Enter UIKit.
To say iOS became a shooting star, Apple’s crowning achievement, would be an understatement. It’s wildly popular amongst users and developers alike. So much so Apple has kind of pushed macOS into the background and allowed its younger brother to take center state. It’s not that macOS isn’t popular — because it is — it’s just that iOS is much, much, bigger than anyone could’ve estimated. As a result Apple spends most of its time working on iOS, or at least it seems that way.
Obviously that would be hugely upsetting for the Mac and iOS ecosystem. But on the flip side it would give developers a clean slate to work with. Something designed to work for touch and mouse and keyboard input. It would give Apple the chance to shake off years cruft and reimagine applications and frameworks without the constraints imposed by Cocoa or Cocoa Touch.
Am I crazy? Yes, a little. I know current developers — especially Mac developers — would lose their minds. It would be the second time Apple changed direction on them in a potentially radical way. This wouldn’t be quite so egregious. The move from Mac OS 9 to Mac OSX was monumental. A brand new OS and a brand new way to code, not easy to adjust to after years of working with an OS and API. Carbon eased folks into it, but the transition was still extremely difficult for some development shops, like Adobe.
Of course they don’t have to go all in. I doubt they’d be that extreme. There are simple things they could do to unify Cocoa and Cocoa Touch. An extremely simple example I can think of is unifying NSColor and UIColor. Over time we’ve seen some text attributes move to their NS* counterparts, why not start with the simple things and work down the stack?
I also don’t consider going from iOS to macOS cross platform. I know they’re slightly different but they are in the same family. If you’re doing iOS development macOS should feel somewhat familiar to you. Sure the controls are different on the platforms and there’s the matter of touch vs. mouse driven, but I believe calling Cocoa based applications cross platform between Mac and iOS is a bit of a stretch. If you’re taking one set of code from iOS to Windows that is what I’d consider cross platform.
Post WWDC 2018 Thoughts
I penned everything above quite a while back, March 11, 2018 to be exact.
While on stage at WWDC Apple announced UIKit for Mac. Four UIKit for Mac applications will ship with macOS Mojave this fall; News, Stocks, Home, and Voice Memos. This is great news for anyone interested in bringing their own iOS Applications to macOS. It means Apple is dogfooding UIKit for Mac while it’s in active development. From all reports it’s really rough around the edges but we can all hope some of those edges are smoothed out before Mojave makes its debut but it’s ok if the applications and framework are a bit rough at first. Why? Apple said on stage UIKit for Mac wouldn’t be generally available until 2019 and that it was a multiyear project. This tells me we should expect a gradual move of UIKit downward into AppKit until UIKit either becomes a part of AppKit architecturally or the Mac specific bits of AppKit become a part of the “new” UIKit for Mac.
In many ways it feels like UIKit for Mac is the right direction. It’s been running on macOS for 10 years. If you’re a developer you’ve used the Simulator everyday to run your iOS Apps on your development machine.
Any developer will tell you shipping software is difficult, especially if you’re driven by deadlines and not feature sets. Given Apple have already announced four applications shipping with Mojave they’re going to have to make really tough decisions to make sure these select applications are ready by fall. It seems reasonable to expect these first UIKit on Mac applications will have a decidedly wonky feel, not quite native. There will be telltale signs, little things, that drive native app seeking people crazy. Things like seeing a UIAlertController instead of an NSAlert when an app needs to inform you of something or ask a question. It makes the application feel unnatural.
At the beginning I’d expect UIKit for Mac to either reach down into AppKit to do the work or reach under the hood and use the same lower levels AppKit uses. Conceptually this is how UIKit living on top of AppKit looks. It’s a way to bootstrap your new Framework into being. Leveraging what AppKit already does seems a reasonable way to just make it work.
As time goes by I would expect more of AppKit to move upward into UIKit. UIKit becomes the new preferred framework for building applications on Mac. Maybe it gets a new name? Maybe not? As that transformation begins taking shape we’ll see UIKit itself transform to feel native on each platform. Mac apps will feel like Mac apps and iOS Apps will feel like iOS Apps. It’s not rocket science. Applications for each OS should feel like they belong. No compromises. Hell, we can write Electron Apps if we want compromise.
As Craig Federighi pointed out on stage at WWDC this is a multiyear effort. Expect things to be ugly at times from the user perspective and the developer perspective. In fact I expect it to be the development effort going forward for iOS and Mac UI Frameworks. Until — of course — the next shiny framework comes along.
A couple weeks back my WordPress weblog started doing funny things. Apparently someone was able to gain access to it via my Jetpack login and install a bitcoin mining service. Joy.
When you’d visit my site you’d occasionally get booted to another site, typically one that wasn’t nice, but on occasion it was what appeared to be a nice weblog. I’m not sure who’s it was but it wasn’t wanted.
So I disabled the site and put up a temporary placeholder page while I figured out what to do about it. This is the second time I’ve had to make changes because my WordPress site was broken into. It makes having a blog a lot less fun when idiots break you stuff.
I decided I’d install Hugo and figure out how to use it to automagically post on my server. I found a nice page documenting how to use git with git triggers to publish a Hugo based weblog and went about trying it out. It works fine, but there is something I can’t figure out.
When publishing I would like to have my front page contain some number of blog posts with permalinks to those posts. E.G. Clicking on the title would take you to a URL like
. Notice the yyyy/mm/dd format in the URL. I want that exact thing for my Hugo pages so I can import what I already have and not mess up links to my existing posts. Hugo looks like it can do this, but there’s one thing that bugs me and I haven’t been able to figure it out.
Can someone please let me know if Hugo can generate a standalone HTML file and drop it into a directory with yyyy/mm/dd format so I can maintain what I already have? If I can do that I’m all in with Hugo. Otherwise it’s off to find a fully baked blogging system that can do what I want.