There are multiple versions of IBM mobilefirst platform available. What are the different decision points that need to be considered for choosing a particular IBM mobilefirst version for implementation?
There are only two versions that should be considered at this time: 7.1 and 8.0, and the only reason to choose 7.1 is if you've already invested in a version older than 7.1. The reason I say that is because V8.0 is rearchitected in a number of significant ways that make it more suitable for Cloud deployments and Open development models. Therefore, the cost to migrate from an older version to V8 is somewhat greater than to migrate to 7.1, and 7.1 will continue to support all the latest mobile operating systems. V8 on the other hand has many new features that 7.1 will never have (as you'd expect) If you're looking to play with the technology, go download the free DevKit from https://mobilefirstplatform.ibmcloud.com/.
So bottom line: If this is a new deployment/purchase/etc. then I'd always suggest V8 as the preferred choice. However if you already have an investment in older versions, V8 is still the preferred choice, but migration to V8 may take more time than to migrate to 7.1.
Does that answer your question?
Mobilefirst 7 or 7.1 will be most reliable as of now since it has been in the market for some time and most of the pmr's would already be resolved. Within 7 and 7.1 itself there are few changes like 7 has desktop browser environment which is not present in 7.1. So you would want to check out the differences before chosing 7 or 7.1. But personally I would recommend you to go for mfp8 since there are lots of new features added into it. It might be a bit unstable but eventually everyone would upgrade to 8 is what I feel.
Related
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 an old mac OS application developed in Mojave with the deployment target 10.12. Now how to update mac OS application to support Catalina? Or is the application automatically supports all future mac OS versions?
When developing for macOS (or any other Apple platform, for that matter), there are two key concepts to take into account when thinking about compatibility:
The SDK version: this is the SDK you're compiling against and it is usually determined by the Xcode version you're using to build your project.
The Deployment Target: this is the lowest OS version you want to support.
Normally, if you have followed the best practice in implementing your code and all of your dependencies have done the same, updating an app for a new macOS version requires only to download the latest Xcode on the latest macOS, build it and run your smoke tests (manually or through automated tests).
There may be things that have been deprecated in the meantime and Xcode will report them as warnings while building. You may read more about deprecated APIs in the macOS 10.15 release notes.
Keep in mind that you don't actually have to rebuild your app every time a new macOS version comes out. Even though it is better to test it at least once and dedicate time to explore and make use of new APIs, apps built on the previous version of macOS will, most of the times, run flawlessly on the next version (and maybe even further). This obviously depends on the app complexity, so your mileage may vary.
I have NVIDIA driver v 378.92 installed, and according to the nvidia website since driver version 377.14, driver supports vulkan api 1.0.42.1. My vulkan SDK api version is 1.0.42.2. However when I check for my device support info, using vkjson_info.exe in the vulkan SDK, there's stated that only apiVersion 1.0.37 is supported.
I'm a bit confused how this works, can anyone enlighten this?
The reported version could be limited by the Vulkan Loader/Runtime it finds. First is this Windows or Linux?
If you have the Vulkan SDK 1.0.42.2 installed, can you run the VIA tool? It should generate an HTML output. If you look at the "Runtimes" section, you should see which ones are available and which one it's using. For best results, try running it from the same folder as vkjson_info.exe. But, it should give you a good idea if you just run it anywhere.
"1.0.42.1" is not a Vulkan version. Vulkan only has three levels (i.e. major.minor.patch). So the "1.0.37" is likely correct and the "1.0.42.1" is likely the version of some LunarG Vulkan SDK or possibly Vulkan Runtime that comes with it.
There are usually several types of versions flying around:
The Vulkan driver version. It is of the major.minor.patch format and it is in VkPhysicalDeviceProperties::apiVersion or can be obtained by a tool such as VHCV.
Optionally SDK/Layers version on the runtime machine. LunarG Vulkan SDK versioning of the form vulkan_major.vulkan_minor.vulkan_patch.optionally_SDK_patch.
Vulkan Runtime of the runtime machine — It is basically The Vulkan Loader dll (if the application uses that). Both SDK and drivers install this (and coexist) and they use their own versioning scheme. The SDK version also installs the Validation Layers to the system.
SDK/Header on the application developer machine. Versioning as described above. The vulkan.h header is always 1.0 and so has only single number version — VK_HEADER_VERSION (which matches the Vulkan patch version — but does not have to in the future)
SDK/Header on the driver developer machine. Versioning as described above. Should really be the same as Vulkan driver version. And most likely the Vulkan RT installed by the driver will be the same version. But I think I have seen this to differ.
It should not matter, because all patch versions are supposed to be both-ways compatible (in reality not really — there were some changes, but driver makers seem to keep up so far providing updated drivers, so it is not an issue). And in fact that is the only thing I could find in the driver documentation: "Vulkan 1.0" support.
I hope you are so enlightened now that you reached the ultimate state of boredom.
377 is a beta version driver from https://developer.nvidia.com/vulkan-driver . There is no guarantee that beta feature will be carried over to the subsequent release version. And according to http://vulkan.gpuinfo.org/listreports.php it didn't (378 indeed have 1.0.37 and 377 have 1.0.42 and more importantly has the extensions you want to try). Continue to use the beta for now if you want the features within it. As for Layers and other SDK features you should not need newer drivers — in fact you should always use the latest to benefit from Validation Layer bugfixes and improvements.
We are using Worklight enterprise 6.2 with fix packs and we are planning to upgrade to 6.3 in the next month (beginning of May 2015). However, we see now that IBM is about to release MFP 7.
Can you please clarify to me those queries:
What is the impact on the project which has been developed on version 6.2 to be moved to 6.3 or 7?
What is the recommendation for us in terms of upgrading, should we go immediately to WL7 or to 6.3 first?
We are very close to the production and our concern that the WL7 "might" be unstable or contains issues that we might face in a critical time."Feedback would be appreciated"
MobileFirst Platform Foundation 7.0 is not about to be released - it is already released.
Lots of changes in both 6.3 and 7.0. Read the documentation to see what's changed...
6.3: http://www-01.ibm.com/support/knowledgecenter/SSHS8R_6.3.0/com.ibm.worklight.getstart.doc/start/c_release_notes.html
7.0: http://www-01.ibm.com/support/knowledgecenter/SSHS8R_7.0.0/com.ibm.worklight.getstart.doc/start/c_release_notes.html
In terms of your project structure, starting 6.3 the adapter thread pool has been removed and you are now in complete control of it. Your adapter XML will be upgraded to the new structure.
In terms of technology, starting 7.0 there is REST support together with a new authentication mechanism - OAuth. Classic authentication is as before and is still there. There are also now Java adapters in addition to JavaScript adapters, and lots more.
7.0 is indeed new, but provides you with a lot of new possibilities.
6.3 is very stable (that is not to say that 7.0 is not stable, but it's also very new).
We cannot decide for you if to upgrade or not, it sounds like you are already considering the right things to consider.
Read about the two releases.
I heard that JBoss 7 is not certified for FreeBSD - is that correct?
Where can I find a list of supported platforms? (I spent some time googling, but was not successful)
Strictly speaking there is no certified OS for JBoss 7 as only JBoss EAP 6 is supported by Red Hat.
The supported configuration for JBoss EAP 6 (the supported version of community JBoss 7) can be found here: https://access.redhat.com/knowledge/articles/111663
As JBoss is pure java application, a compliant JDK is enough to have a supported system. So if you have the Oracle or IBM JDK running on FreeBSD is will be supported by Red Hat. But they haven't test them with JBoss.
Any way if you want Red Hat support for the EAP you better check with there representative to discus the extends of the support (if the FreeBSD JDK have some compliance bug, they will probably send you back to the JDK supplier. If you chose RHEL with OpenJDK you will have one supplier to blame for any software stack issue, no redirect to another suplier.)
For community JBoss as for other platform, you will be responsible to make it work with your stack. An good first test can be performed by running the standard compliance tests included in the JBoss sources, if it runs on your target platform and JDK it is a good sign that JBoss is working on it.
Certified Support as per Redhat only goes up to 6:
https://access.redhat.com/knowledge/articles/111663
However if you look back at the release docs they have not changed. OS's are the same.