TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Mac apps are harder than iOS apps

87 点作者 mronge超过 11 年前

16 条评论

drewcrawford超过 11 年前
So I have this question that&#x27;s been eating at me for a few days, and I can&#x27;t find anybody who knows the answer and is willing to talk about it.<p>When I find myself wanting to write Mac (as opposed to say iPad) software, it is not always but usually because having a hardware keyboard is important to whatever software I want to write, and of course all Macs have hardware keyboards. There are other reasons, like better interoperability with other desktop software, but these seem to shrink each year.<p>But it occurs to me that with iPads outselling Macs at a ratio higher than 4-to-1, it seems at least plausible to me that either there are, or could be in the forseeable future, more iPad users with hardware keyboards than Mac users. So if you are trying to target people who use a keyboard, the iPad could be a better bet.<p>I can&#x27;t find any numbers so I don&#x27;t know if we are there already or if we are a long ways off. But this line of inquiry has really caused me to question whether the iPad makes more sense than the Mac for a lot of projects that I have formerly just assumed would be a better fit for a desktop form factor.
评论 #6438359 未加载
评论 #6438961 未加载
geuis超过 11 年前
I have been working on a Mac app off and on for a few months. I don&#x27;t have any background in native programming though, as my experience has been pretty much completely from web engineering and javascript&#x2F;Python.<p>My biggest issues have been 1) Lack of a development community and 2) Both too much documentation and not enough.<p>1) The Mac dev forums from Apple are almost dead. Asking a question on StackOverflow is a literal crapshoot as to whether you&#x27;ll get an answer or not. I don&#x27;t know where to begin looking for an active, vibrant Mac developer community.<p>2) Apple&#x27;s documentation is simultaneously rich and deep while being incredibly sparse, inconsistent, and maze-like. Very frequently you can find a description on SO or a blog post referencing something you need, yet the link is broken because Apple is very bad about maintaining and forwarding links when they change their URL structure.<p>There are entire classes of questions that I don&#x27;t even know how to research or ask about yet I know should have answers when I encounter them.<p>Not too long ago I was doing something with AVFoundation. There was a particular setting that I needed to change, and by looking at the signature of a similar feature that plugged in the same way I knew it should be there. But I couldn&#x27;t find it. The docs in this feature said nothing about it. I searched high and low for 2 days for sample code or anything that implemented this thing. I was getting nowhere.<p>I finally went back and watched the original 2 WWDC videos where AVFoundation was being introduced in 2011. After 2 hours and literally in the last 2-3 minutes of the 2nd video, the speaker casually mentioned the feature I was working with. I about flipped my lid at that point.<p>The property was exactly where I expected it. Xcode wasn&#x27;t autocompleting it for some reason and I think there was a camel-case issue that was making it fail. All in all it was extremely frustrating.<p>I&#x27;m being vague about the details because this all happened about a year ago and I haven&#x27;t thought much about it.<p>If anyone knows if&#x2F;how you can display a window in the app while recording the screen with AVFoundation and not record that window, you&#x27;d save me a ton of time and frustration. Otherwise I fear I have to stop using AVFoundation and do my own implementation which I think is a very bad idea.
评论 #6439728 未加载
评论 #6439856 未加载
评论 #6439575 未加载
评论 #6439649 未加载
jlarocco超过 11 年前
Most of these &quot;problems&quot; actually sound like good things to me. It&#x27;s more difficult to override stuff like the title bar for a reason.<p>Mac apps aren&#x27;t iOS apps, and if you&#x27;re developing them as if they are, you&#x27;re app is going to look goofy and ugly running on OSX. Your app isn&#x27;t as special as you think; it should use the standard conventions like everybody else.<p>That said, there are a <i>very</i> few apps where going away from the conventions can work. Lightroom comes to mind, but there might be others. In any case, it only works if it&#x27;s done all the way and not half assed, which I&#x27;m not sure 99% of software companies are capable of doing. If Adobe wasn&#x27;t a mega-corporation with tons of money to throw at it, they&#x27;d probably screw it up.
raimue超过 11 年前
&gt; On the Mac if you want to customize the window title bar, you are going to be in for a world of pain. Apple provides no API for customizing things like the title bar on OS X.<p>That is not really a downside. Why should the title bar be customized by an application? The title bar is used for the window management by providing controls to close, minimize, resize, and move the application window. This behavior should not be customizable by the application at all.
评论 #6439336 未加载
makecheck超过 11 年前
Cocoa has actually evolved significantly. There was a long period on the Mac where the (now legacy) Carbon and Cocoa APIs didn&#x27;t overlap too well. In fact, <i>both</i> APIs had things that the other API couldn&#x27;t even do, and <i>both</i> APIs had strengths in completely different areas. I think by about the time 10.3 Panther was released Cocoa had filled in a lot of the gaps, and Apple eventually decided to not port Carbon to 64-bit at all. Carbon remains functional but it&#x27;s almost completely deprecated.<p>As great as versions like Mac OS X 10.3 were, later versions of the Cocoa API are noticeably better. In fact, it&#x27;s now hard to support anything earlier than 10.6 because of improvements to libraries (e.g. more native UI views available, more features per class), improvements to the compiler and other developer tools (e.g. ARC), and changes to the language (e.g. blocks).<p>As of Mac OS X 10.8, the Cocoa frameworks are decently in line with iOS, far beyond the simple stuff like NSArray; for example, AVFoundation.framework and GLKTextureLoader now exist on both platforms which is useful for consistent game development.<p>Cocoa is also more customizable than you might think. While technically Cocoa won&#x27;t allow certain view or window properties to change, an <i>illusion</i> of a change can be just as effective and is straightforward (not to mention being more stable for the OS in the long run). For instance: maybe you create a mostly-transparent borderless window at a specific location with a certain Z-order, in which you draw what <i>looks like</i> a window frame modification; this is often exactly what is required even though the window underneath didn&#x27;t actually change at all.<p>I have my own share of frustrations with Cocoa in spite of what I&#x27;ve said. Cocoa is <i>not</i> perfect and I do think they still have some work to do in terms of improving sync with iOS and making it a lot more powerful. A pet peeve of mine is that APIs often lag far behind new OS features (e.g. new UI paradigms...it seemed to take forever for Spaces to be properly handled in the API).
programminggeek超过 11 年前
Isn&#x27;t this part of the reason why there&#x27;s some effort to port some of the iOS UIKit to OSX? <a href="https://github.com/BigZaphod/Chameleon" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;BigZaphod&#x2F;Chameleon</a>
评论 #6438577 未加载
评论 #6438906 未加载
CGamesPlay超过 11 年前
I&#x27;m willing to bet that the next major version of OS X will do away with AppKit and bring UIKit to the desktop. UIKit is already API-compatible in many ways and most of the pieces are already in place.
评论 #6439504 未加载
评论 #6439804 未加载
评论 #6439928 未加载
评论 #6439892 未加载
outworlder超过 11 年前
Good article.<p>Now, try the Win32 API, then go back to Cocoa. That will put the &quot;pain&quot; into perspective.<p>OSX developers are writing at the same level as C developers using Win32 directly, but with a much nicer, object-oriented API.
评论 #6441425 未加载
评论 #6440325 未加载
johnwatson11218超过 11 年前
One thing that I found confusing about writing mac apps was the vestiges of the old memory models. When I started a new project I just clicked the checkbox for Automatic Reference Counting and assumed I was coding in something like Java. I didn&#x27;t think about memory management anymore.<p>I remember having to add annotations to the auto generated getter&#x2F;setters to inform old memory management systems how to treat things returned from the methods (I&#x27;m sure I stated that incorrectly but it has been a while). Bottom line is that it was hard to know what was no longer required when coding with the latest release. If I read tutorials that were a few years old they would confuse me with aspects of memory management.
评论 #6439298 未加载
6cxs2hd6超过 11 年前
&quot;Why I&#x27;m not writing OS X apps&quot;, by Hipster Programmer: <a href="https://plus.google.com/u/0/107370779337689020644/posts/8SWfTAtS8LX" rel="nofollow">https:&#x2F;&#x2F;plus.google.com&#x2F;u&#x2F;0&#x2F;107370779337689020644&#x2F;posts&#x2F;8SWf...</a>
评论 #6440881 未加载
PixelCut超过 11 年前
Making custom OSX controls is easy with PaintCode (<a href="http://www.paintcodeapp.com" rel="nofollow">http:&#x2F;&#x2F;www.paintcodeapp.com</a>). It is a vector drawing app that generates Objective-C drawing code.
评论 #6440092 未加载
nikolakirev超过 11 年前
The Layout is also a very tricky part. On iOS the app is always in full screen. On OS X, there are infinite number of display sizes and the user can dynamically change the size and ratio of the window of your app.
评论 #6438909 未加载
zulfishah超过 11 年前
So true. I&#x27;ve been working on my iOS app for about 4 years now, and recently started work on porting it to the Mac. But it&#x27;s so much more tedious than I expected, for exactly the reasons you mention: lack of documentation and support, lots of subsystems to work on, legacy controls that aren&#x27;t customizable. Attending WWDC and talking to people on both AppKit and UIKit teams, it&#x27;s striking how little they seem to collaborate; it&#x27;s like they live in their own organizational bubbles, and there is very little push from on top to make them more streamlined. They have made some progress on some frameworks to consolidate them across Mac OS and iOS (MapKit comes to mind), but it feels like they still operate as two independent entities within Apple; one being the young hot-shot with all the resources, and the other being the envious legacy-system that knows it&#x27;s past it&#x27;s best.
bengoodger超过 11 年前
Desktop window manager integration seems to always be tricky. I&#x27;ve personally sunk months of my life in getting a variety of custom window frames to work &quot;well enough&quot; on various Windows flavors (for Chrome on XP, Vista, 7 and newer). I think part of the benefit of these new mobile platforms is their simplicity - there is less going on outside the app&#x27;s control at any given point in time, so there&#x27;s less to worry about.<p>(On Windows, there are several ways to achieve a &quot;custom-ish&quot; frame, but only if you really study the window manager-app interaction and think about the problem as if you were the window manager can you come close to doing a proper job of it... handling the right messages (some of which are undocumented and only discovered via using spy tools), responding in the correct way etc.)
joshdance超过 11 年前
Good read. I like the examples. I have been thinking about writing some Mac Apps. This made me rethink it. :)
评论 #6438612 未加载
评论 #6438579 未加载
评论 #6445931 未加载
gdonelli超过 11 年前
This guy has been writing Obj-C for 10+ years! woot!