I'm soon going to release an app for Windows Phone 8.1, using Nokia's imaging SDK. However, the Nokia Imaging SDK does not support the Any CPU target platform, so I have to choose between building towards x86 (for the emulator) or ARM (for my phone).
Is it safe to only upload an ARM build to the marketplace or might I lock out some users that way?
As far as my knowledge goes, it's perfectly safe to upload ARM-only packages.
Related
I want to run IOS Simulator on Windows 10.
Is there a way to do this?
I dont think its possible to get the iOS simulator working on Windows. But if you are willing to explore a dual boot setup, have patience (and a supported motherboard/processor), then you could use OpenCore or Clover to get a macOS running on your pc. This will give you access to the iOS simulator and the other xcode tools.
If you take this route then you should know that macOS doesnt support ntfs writes out the box. This means that if you decide to create a shared volume that both the mac and windows partition would read and write from, then you would either need a 3rd party ntfs drive (e.g. macfuse) or to format your volume to exFAT (this gave me the best results and was free)
If you intend to run the latest macOS I would recommend going with OpenCore. The latest Clover versions ports pieces of OpenCore to it, and finding documentation on configuring the new Clover was a hassle for me. If you are fine with running Catalina and using an older xcode (and thus older iOS simulator), then I would recommend giving tonymac tools a shot. Building the installer took with very little effort. You need an account to download the tools (this is free but they ask for motherboard/gpu model for community posts and verification that you can actually run their software)
Native testing of iOS apps is only possible on an Apple device. But there are some ways to overcome that.
Some reference to external iOS simulating platforms: https://fossbytes.com/best-ios-emulators-pc-windows-mac/
Can ios apps be compiled on the new M1 chipset?
Is there any schedule for official support?
The short answer is yes.
The latest version of XCode (version 12) is compiled as a universal app. This means that it runs on both Intel-based and Mac Sillicon machines natively. From Apple's website:
Xcode 12 is built as a Universal app that runs 100% natively on Intel-based CPUs and Apple Silicon for great performance and a snappy interface.* It also includes a unified macOS SDK that includes all the frameworks, compilers, debuggers, and other tools you need to build apps that run natively on Apple Silicon and the Intel x86_64 CPU.
This means that you should be able to compile iOS with the latest version of XCode without a problem. It would be kind of crazy for Apple to release professional hardware (MacBook Pro) without this capability.
Keep in mind that a number of third party applications may not work well on the ARM machines yet. VSCode is not currently supported on M1 devices (although Microsoft have said that it's coming). VSCode is an Electron based app which currently can't be emulated with Apple's Rosetta II platform. You might not use VSCode, but keep in mind that any Electron based apps that you use may not work straight away.
If you exclusively use XCode and don't critically rely on any third-party apps you should be ok.
EDIT: I just noticed that you tagged your post for react-native. Information is pretty slim for compatibility at the moment, so I would be cautious. If you need a Macbook Pro to do commercial work or school projects right now then you run the risk of things not working as intended. The M1 MacBooks will undoubtedly support everything that you need as a developer in the future and they're particularly great candidates for iOS development because of the parallels made possible by the shared ARM architecture.
If you're relying on a new machine to get work done right now, going with an Intel-based machine is probably the best option. For reference, I recently got an Intel-based 16" MacBook Pro with work because I need to get things done right now without any issues. The commercial value far outweighs the potential benefits that an M1 machine might bring in a year or two. If you're ok with running into some issues over the next few months, I'm sure that the M1 machines will provide plenty of value for years ahead.
While there are problems that do not allow compiling the application.
brew and cocoapods are installed in the console with rosetta enabled.
pod install / update fails because flipper and some parts of RN are not supported by the platform
if you use expo - without cli then everything is ok
updates: now cli working (after update all - homebrew, cocoapods and other to last version)
from what I know, iOS app only compiles on Mac os, so it should work with whatever macOS uses.
I have a few programs I'd really like to test on Windows 8 for ARM. I don't have any Windows 8 ARM hardware though. Is it possible to install Windows 8 in some kind of ARM emulator or some such?
Yes, I know that if it compiles on WinRT it is suppose to "just work", but I'd really like to test it not only to see if it works, but also relative performance(as much can be guessed from an emulator)
There is no way, how to start you x86 PC in an "ARM mode", or launch Simulator in ARM mode. WinRT was designed to bridge the differences or these platforms so you don't need to worry about it and you can just develop. All I can think of right now is try to contact local Microsoft representative in your area - if they have any ARM tablet for testing, they might help you in this, but again if your app is not really flawed or computing power demanding, don't worry about the ARM platform :)
This now appears to be sorta possible (haven't tested yet) with the new App Ceritification Kit for WinRT, which appears to include ARM emulation.
EDIT: This isn't an emulator, it will only run on an ARM WinRT device. I guess there is no ARM emulator, despite that page mentioning ARM and emulation
Hi!
I have an old plugin (as binary, dll), used by my application. It was build for WM2003. And now it crashes the app, if loaded on Windows Mobile 6.1 (WM5 works fine, WM6 too).
The source code is not available and it's no more supported by developer. So I can't rebuild it for WM6.1.
Is it possible to patch or convert the binary to allow it to work on WM6.1 ? If so, how can I do this ?
Thank you.
Edit: I've found, that the problem is in PE loader, which acts not the same on WM6.1 (comparing with WM6 and earlier).
Does this plug-in use MFC or ATL? Earlier versions of WinMo had a different ATL/MFC version baked in, so MFC or ATL apps written in Studio will not work unless you deploy the newer ATL/MFC libraries along with the app, just as the old apps will not work on new devices unless you deploy the old MFC/ATL libraries.
This problem is rare, but some information can be found.
The common solution is to rebuild a binary in VS2008 (TCPMP new VS2008 builds for WM6.1), but this will not help, if you don't have the source code.
I've found the problem explanation and another solution in cegcc mailing list (arm-wince-cegcc on Windows Mobile 6.1). In Windows Mobile 6.1 Memory Management scheme was changes.
This slot arrangement remained pretty constant from Windows Mobile 2003 to Windows Mobile 6.0. However, with the release of Windows Mobile 6.1, things were changed to reduce the DLL pressure and to help out in the Device Manager process space.
In Windows Mobile 6.1, the stacks for the device manager are no longer allocated in the processes’ slot. Instead, the operating system uses slot 59, at the top of the Large Memory Area, for the device manager thread stacks. ...
And the workaround for this issue is to declare the DLL in registry (to tell the OS not to load it in high memory).
I don't like this workaround, so I try to find some binary patcher. And found it :)
It's not really a patcher, it's UPX - the Ultimate Packer for eXecutables. But it solves the problem perfectly. The DLL, packed with UPX don't crashes the application and runs fine.
I've noticed that all betas for Dropbox are released simultaneously for Windows, Mac and Linux. How do they do that? Anyone knows which platform they're using? I'm aware that there are many native -very impressive, actually- functions in each of the platform clients, but they seem to release critical bug fixes efortlessly for all platforms.
So any idea of which GUI platform they're using?
The Linux version includes files such as wx._windows_.so, libwx_gtk2*.so, etc. (I haven't checked the others), so I suspect Dropbox uses wxWidgets.
Qt is a popular cross-platform application and GUI framework with native look-and-feel.
I don't know what Dropbox uses for all its supported platforms, but it looks like its linux client uses at least Gtk: Dropbox linux System Requirements.