I just upgraded to Flash Builder 4.5, and I am trying to decide whether to install the Win or OS X version, since Adobe only allows you to install on one platform. I have been, up until now, developing an AS3 application using FB 4 under Windows 7 on my MacBook, and my Production Premium CS5 license is also for Windows (and I also do C++/Visual Studio development as well). Now I am going to try the iPhone Packager, to port my app to iOS. It seems to me that the workflow will be awkward once I cross-compile to Objective-C - as I will need to either reboot into OS X to compile and debug, or I will need to run FB 4.5 in a parallels session under OS X (though Adobe's activation freaked out when I tried this with Prod Prem CS4). The FB 4.5 / iOS workflow still requires xCode does it not? Is it foolish to even try this? Should I just bite the bullet and switch over to working in OSX?
Thanks!
I'd say it's better to keep things simple and stick with OSX. Constant switching among platforms is a sure productivity killer. Bite the bullet and stay on OSX - it will pay off on the mid run.
You're better off doing all of this in OSX
Related
I'm developing an app in objective-c using Xcode 8. (because old computer)
Currently, my only options for the NSView's appearance are (Default) Aqua, and Aqua.
However, in SDKs starting in 10.14, they've included Mojave's Dark Aqua.
I've added the 10.15 SDK (https://github.com/phracker/MacOSX-SDKs/releases) and added it to XCode (/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/) and set the project SDK to it. However, I still don't get the choice to use Dark Aqua.
What should I do? (Alternatively, I could use https://github.com/insidegui/AssetCatalogTinkerer, but when I build it [as it does not include a build with it], I get errors when using the .car it generates.)
With hope,
Conrad
What should I do?
Get yourself a VM app (e.g. VMWare Fusion, Virtual Box, Parallels) and build yourself a Mojave VM then develop & test your app within that.
You will pay a small performance penalty, that's an objective observation of course and YMMV – especially if you're doing heavy graphics – but developing in a VM is quite doable. Indeed when Apple release 10.16 betas, you want to get your software ready, and you don't have a spare machine, then installing it on a VM is far safer than risking it on your primary machine.
HTH
I actually built a Hackintosh to learn programming with Xcode. It runs on my Asus X555LA laptop. I downloaded the latest Xcode 9 GM build from the Apple Site (not from App store). After extracting, when I tried to install, it shows "You can't use this version of the application "Xcode" with this version of macOS; You have macOS 10.12. The application requires macOS 10.12.6 or later".
Is there any tweak to make it run on my Sierra 10.12 itself? I can't really think about upgrading the macOS version as it's a Hackintosh. I followed this guide to install macOS on my Asus laptop.
Xcode requires latest macOS, you have no choice, you need to upgrade the macOS version on your Hackintosh. Or better: Reinstall macOS in a recommended way on your PC, if you're doing Hackintosh... :)
The guide you linked is very poor... Never use premade install images, because these have been modified in an uncertain way, and you don't want to install a premade undocumented mess to your computer. It might be packed with threats, malwares, spy tools and so on.. It's the worst thing I can imagine in security aspect to install an OS image from uncertain source.
Also, there is no universal macOS installer for PCs - even though many are trying to find a way to create it: it's a bad idea and it will never succeed because there are so many PC parts, millions of differently built computers..
The only way to create a stable fully functional Hackintosh is to know your hardware and create an installer flash drive for that specific PC. First you have to download the latest macOS Sierra from AppStore, this is the only source that you can trust, because it's downloading from Apple's servers. Then install a small program, called Clover bootloader to the flash drive to make it bootable.
This is the only full and up to date guide for PC laptops. If you have questions, register to the linked site and start a new forum thread posting your questions. They will help you but please read this guide at least 3-4 times carefully because everything is described here.
There is an an AIR app which is being maintained, and for the time being, things were alright. Up until Dec. 08 when AIR update 20.0 came in, leaving an error message
"The required native extension is missing for this application. Try re-installing or contacting the publisher for assistance".
A lot of people have been seeing same, so it must be a common problem - that AIR update broke down all native extensions, like:
https://scratch.mit.edu/discuss/topic/172434/
https://support.magplus.com/hc/communities/public/questions/207651297-Adobe-AIR-The-required-native-extension-is-missing
etc. etc.
Is there any definite fix, or all we have to do is to sit and wait for Adobe to issue a fixed version? People suggests downgrading to version 19.0 but it seems impractical for any massively used app, most users will simply give up on it rather than downgrade.
Air 20 on OS-X made the jump to 64-bit (Windows 64-bit will be released next) and thus any ANEs would need to be compile for ARCH x86_64 and the Air application re-packaged and published to work on the Air 20 runtime.
If you need both runtimes you can install Air 19, rename name the installer to something else, i.e. "Adobe AIR Application Installer 19.app" and then install Air 20...
AIR 64-bit on Mac OS X
The AIR shared runtime and SDK are now fully 64-bit on OSX!
With AIR 20, all Mac AIR applications will be 64-bit compatible.
If you require 32-bit compatibility for OSX, please continue to use AIR 19 to create captive runtime applications.
Re: https://forums.adobe.com/thread/2051806
after reading the apple SDK guide
https://developer.apple.com/library/mac/#documentation/developertools/conceptual/cross_development/Overview/overview.html
I'm still confused of how to make the mac app backward compatible & how to test them properly
I have an app, I run it and tested it on Mountain Lion 10.8 without any problem, however I want to make this app backward compatible so that other users can run it on a mac 10.6 - 10.7 machine.
I have an apple developer id and I can download the old versions of 10.7 and 10.6, but the problem is, I have a 2011 macbook air which is currently running 10.8, and that's the only apple machine that I have. Can I test the 10.7 and 10.6 by using vmware or parallels?
in my project settings, I set the target deployment to 10.6 (as I want 10.6 users to run my app), but should I set my SDK to 10.8 or 10.7? if I set the SDK to 10.8 but having the target deployment set to 10.6, if I fix all the xcode warnings will it run successfully on 10.6??
from the SDK drop down, I can only set to 10.8 or 10.7, but 10.6 is missing, how do I fix that?
thanks in advance
I develop on a 10.8 box and support back to 10.5. Just a couple of months ago we dropped 10.4 PPC support, and I'm still cleaning out some of the 10.2-specific code. This may get a little rant-y, but I've been doing old versions for a long time. I have some opinions on the matter.
No matter what Apple says in their docs, if you want to support 10.6, then build with the 10.6 SDK. Do not rely on distribution target.
I have had this discussion with the Xcode engineers, and while they hold to Apple's party line that you should always build with the latest SDK, they also acknowledge that it's generally insane to do so. If you build against the 10.8 SDK and mark your deployment target at 10.6, you will get no warnings for using methods that do not exist on 10.6. The only way you will discover that you've used a nonexistent method is that it might give you strange bugs when run on 10.6. That's insane.
Remember, OS X doesn't crash when you send an unknown selector. It just aborts the current runloop. So the bugs are even harder to track down then on iOS, where it crashes the app.
Sure, you can do weak linking. Talk about dangerous.... Yes, there are a few times this is useful, but the compiler gives you no warning if you don't do it correctly. If I'm going to do weak linking like this, I go the other way, linking against the old SDK and copying the new function's prototype into my implementation. That way I have documentation of every function I think I'm going to weak-link.
Download the old SDKs and symlink them into your Xcode distribution.
Guard them jealously. Apple will try to delete them every time you upgrade Xcode. Make your own copies and stick them in /SDKs or somewhere else away from Xcode. I provide a script called fix-xcode to manage the symlinks automatically. Am I bitter at Apple for their relentless insistance on deleting my old SDKs? Yes, I am.
You can run 10.6 Server in a VM legally. You can run 10.7+ Desktop in a VM legally. These are good ways to test your code.
Or you can do what I do and have a small pile of old MacBooks each with two or three partitions on them that you reboot all the time.
Now that 10.7 comes from App Store, it's a little harder to make VMs. My strong recommendation is to snapshot your image immediately after install, and make a clean backup copy of it. You'll want to be able to clone that image from time to time when you need to get back to a "raw" machine.
Get in the habit of squirreling away SDKs as they come out. 10.8 will be old some day. You might as well make a copy now while it's easy.
Whether you support individual dot-releases or not, it can be very helpful to keep around the upgrade packages for individual dot releases. When you encounter customers running non-current releases, it's nice to be able to check whether an "unreproducible" bug in fact is easily reproducible on their specific version. Whether this is worth it or not depends heavily on your product and customers. It was a life-saver for me when 10.4.11 made major changes to WebKit during a dot release...
Invest in a small NAS or a big external USB drive (though I've had trouble with those failing when used extensively, so I prefer a RAID). You'll need the space. You want to hold onto lots of VMs and lots of SDKs and sometimes even old versions of Xcode.
Adding to Rob Napier's great in-depth answer:
To use an old SDK, put the SDK (or a symlink) to it here:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs
With XCode 7.3 or later, you need you to open this file and change "MinimumSDKVersion" (otherwise XCode will refuse to use the old SDK):
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Info.plist
You can install multiple versions of Mac OS on a single machine, booting between each.
The SDK should be the latest (10.8).
See 2.
One alternative to 1 that I've considered (I am in the same boat) is to create a Snow Leopard Hackintosh using an old PC and just installing Lion and Mountain Lion on my MBP.
You need to do these settings :
1.Set the Base SDK to Current version of Mac (ex. 10.7)
2.Set the Deployment SDK to older version (ex.1.4)
I recently started creating applications for mobile devices and have successfully completed an application for the iPhone. I am now turning my attention to the Blackberry but haven't been able to find a convincing article or website that states that it can be done or a tutorial on how to do so. Can Blackberry apps be developed on Mac OS X? If yes, how do I go about doing so? Can anyone please point me in the right direction as I only have access to a Mac and really want to get this project on the road. Thanks in advance for your help.
UPDATE:
RIM has released a MacOS Eclipse plug-in for Blackberry Development: http://na.blackberry.com/eng/developers/javaappdev/macosx.jsp
While there is no built-in simulator, the plug-in DOES support USB tethered device debugging for the Torch 9800 handhelds. I plan to get one; they are ~$499 w/no contract. With a Torch and the new plug-in, Blackberry development is possible without using a VM. (Finally!)
PREVIOUS POST:
Building on MacOS works well once you set it up. I've had less luck with the simulator. On the whole though, being able to run Eclipse natively in MacOS and flip to a Windows VM only for debugging is a big win in my book.
You can get a MacOS version of preverify (see link below for details). I do my development with Eclipse on MacOS X and use Ant to build BB apps.
This blog is excellent and has many of the details to get you started:
http://www.azizuysal.com/2009/07/blackberry-development-on-mac-os-x.html (original link is dead. The "wayback machine" provides us with the original text content, but images and styling are lost to the sands of time. Still worth a read.)
The tricky part is getting the simulator to work. There is a Wine-based work-around, but on my computer, while the simulator was able to run under Wine, the LCD output was scrambled.
Currently, I build COD files from Mac, and my Ant build process drops them into a directory that is shared with a WinXP VM. I can run the simulator stand-alone in this VM. Debugging is also possible by installing Eclipse inside WinXP and pointing the debug configuration it at the source directories.
I've actually got a bit more magic. I enabled some of the Java 1.5 features by compiling against 1.5 and then translating the bytecode to 1.3 prior to the preverify script. (Blackberry only speaks a barbaric 1.3 java, flashback to circa 1992). It's not a silver bullet as some features still don't work, but it does cut down on the need to make everything an untyped Object reference.
Lately, I've been working on a x-platform framework to allow me to write app code once and build against both Android and Blackberry (both are Java). The Android part was easy. It's just a bitch to debug anything in Blackberry. Someone working at RIM decided that Blackberry didn't need to keep Exception stack traces unless there was a catch(Throwable), and then they could do something bizarre, non-standard, and undocumented (catching Throwable behaves weird). I've only kinda-sorta figured out a hack to get stack traces using JavaLoader.exe without breaking into the debugger, and it's barely worth it.
p.s., I now do x-platform development with a single code-base targeting Android, Blackberry, and Desktop. Desktop is great for testing app functionality, with very little Blackberry on-device testing needed once features work in the desktop 'simulator' (a Swing GUI built for debugging our games).
Even though certain components of the RIM development platform are java-based, such as the JDE - other components such as the preverifier and device simulators are implemented as native Windows executables.
Basically, the easiest way to do it is to install Windows on your Mac using Bootcamp or Parallels and run inside a real Windows environment on your Mac.
However, there are other "hackier" ways to do it using Wine, MacPorts, and a number of other tools - as an example see this blog post