How to Use Device Instead of Simulator

How to use device instead of Simulator

First you have to get your developer certificate/keys set up on your mac. See the developer portal where there are detailed instructions on how to get this set up.

Once you have your certificate, plug in your device, and press cmd + shift + 2 in XCode - to load up the organizer. Select the devices pane, click on your device, and click the 'use for development' button. It will ask you to put your username/password in for your dev account, and then it will enable your device for development. After it has been enabled, you simply select it as the target to build to in the top-left of the main Xcode window.

How to run or debug on android phone instead of emulator?

You can generally switch on USB debugging on your handset and connect it up to your PC over USB. The handset will then appear to adb in the same way as an emulator. You might need to download drivers from your handset manufacturer for your phone.

On my HTC desire the setting is under:

Settings -> Applications -> Development -> USB Debugging

Running code on iOS device instead of simulator

Does your phone operating system match with Xcode operating system? For example, if your phone has 7.0 and you are deploying the build from 8.3, then of your course, your phone will not match and cannot be detected and will give you that error.

In other words, Check Deployment Target, it should match with your phone operating system, otherwise your device is not recognized.

How to check:
General-->Deployment Info--> Deployment Target

Can't run react-native project in a physical device instead of emulator?

1. Enable Debugging over USB
   Most Android devices can only install and run apps downloaded from Google Play, by default. You will need to enable USB Debugging on your device in order to install your app during development.

   To enable USB debugging on your device, you will first need to enable the "Developer options" menu by going to Settings → About phone and then tapping the Build number row at the bottom seven times. You can then go back to Settings → Developer options to enable "USB debugging".

2. Plug in your device via USB
   Let's now set up an Android device to run our React Native projects. Go ahead and plug in your device via USB to your development machine.

   Now check that your device is properly connecting to ADB, the Android Debug Bridge, by running adb devices.

   $ adb devices
   List of devices attached
   emulator-5554 offline # Google emulator
   14ed2fcc device # Physical device
   Seeing device in the right column means the device is connected. You must have only one device connected at a time.

3. Run your app
   Type the following in your command prompt to install and launch your app on the device:

   $ react-native run-android
   If you get a "bridge configuration isn't available" error, see Using adb reverse.
   Hint
   You can also use the React Native CLI to generate and run a Release build (e.g. react-native run-android --variant=release).

Make sure to shutdown the emulator and only have one device connected.

Read further here :- https://facebook.github.io/react-native/docs/running-on-device.html

How do I run/test my Flutter app on a real device?

For Android, this is pretty easy:

1. Enable Developer options and USB debugging on your device. This varies slightly by Android version, but the short version is you tap on the Device Build Number 7 times. Then a "Developer Options" option comes up and you can click "enable USB Debugging." See the linked Android documentation for the most up-to-date instructions.
2. Then plug your phone into your computer with a USB cable. You'll probably see some popup on your phone asking if you want to allow USB debuggng with that computer. Say "yes".
3. Run Flutter just like you would if you had a simulator running.

Using the right cable can make a difference. If the device is charging but nothing happens, try using another cable, preferably the one that came with the device. A notification on the device (e.g. "connected as a media device") and on Windows (e.g. "Device connected and ready to go") are indications that the USB connection is working. You should then be able to see the device on the CLI with:

flutter devices

For iOS this is a little more complicated because you need an Apple ID or to sign up for a "Developer Account":

1. Open XCode, then open "Preferences>Accounts". Sign in with your ID.
2. "Manage Certificates" > click on the "+" sign and select "iOS Development".
3. Plug your device into your machine. Find your device in the drop down (Window > Organizer).
4. Below the Team pop-up menu, click Fix Issue.
5. In Xcode, click the Run button.

(in subsequent runs, you can deploy to the iOS device with Android Studio, VS Code, or any other IDE of choice, you just need to set up that certificate the first time with Xcode. Here's Apple's documentation on setting up Xcode to run a physical device.)

How to use FMDB on the generic iOS device instead of simulator?

SQLite offers good error reporting and you should avail yourself of it. So, for example, if any of these executeUpdate calls fail, you should examine the lastErrorMessage (before you close the database) so you know why it failed.

Personally, I'd suggest using executeQuery(_:values:) and executeUpdate(_:values:) rather than executeQuery(_:withArgumentsIn:) and executeUpdate(_:withArgumentsIn:) because the former methods throw errors (which shifts to a more active error handling paradigm from the more passive one in which you have to manually remember to check for errors). But regardless of how you do your error handling, do it, or else we're all guessing.

Personally, I'd suggest using Xcode's "Devices" window and download your app's bundle (see https://stackoverflow.com/a/38064225/1271826) and look at the database. I bet it's a blank database with no tables defined at all. In terms of why, it could be because you did some earlier testing and there's an old version of the database in the Documents folder. Try completely deleting the app from the device and re-running and see if that fixes it.

Other, more obscure sources of problem include filename capitalization (e.g. Data.db vs data.db). The macOS file system will often handle that gracefully because it's not (generally) case sensitive. But iOS devices are case sensitive.

But, like I said, we're flying blind until (a) you add some error handling to your code so you can see why its failing; and (b) look at the database on the device to see what it looks like.

How to detect if app is being built for device or simulator in Swift

Update 30/01/19

While this answer may work, the recommended solution for a static check (as clarified by several Apple engineers) is to define a custom compiler flag targeting iOS Simulators. For detailed instructions on how to do to it, see @mbelsky's answer.

Original answer

If you need a static check (e.g. not a runtime if/else) you can't detect the simulator directly, but you can detect iOS on a desktop architecture like follows

#if (arch(i386) || arch(x86_64)) && os(iOS)
    ...
#endif

---

After Swift 4.1 version

Latest use, now directly for all in one condition for all types of simulators need to apply only one condition -

#if targetEnvironment(simulator)
  // your simulator code
#else
  // your real device code
#endif

For more clarification, you can check Swift proposal SE-0190

---

For older version -

Clearly, this is false on a device, but it returns true for the iOS Simulator, as specified in the documentation:

The arch(i386) build configuration returns true when the code is compiled for the 32–bit iOS simulator.

If you are developing for a simulator other than iOS, you can simply vary the os parameter: e.g.

Detect the watchOS simulator

#if (arch(i386) || arch(x86_64)) && os(watchOS)
...
#endif

Detect the tvOS simulator

#if (arch(i386) || arch(x86_64)) && os(tvOS)
...
#endif

Or, even, detect any simulator

#if (arch(i386) || arch(x86_64)) && (os(iOS) || os(watchOS) || os(tvOS))
...
#endif

---

If you instead are ok with a runtime check, you can inspect the TARGET_OS_SIMULATOR variable (or TARGET_IPHONE_SIMULATOR in iOS 8 and below), which is truthy on a simulator.

Please notice that this is different and slightly more limited than using a preprocessor flag. For instance you won't be able to use it in place where a if/else is syntactically invalid (e.g. outside of functions scopes).

Say, for example, that you want to have different imports on the device and on the simulator. This is impossible with a dynamic check, whereas it's trivial with a static check.

#if (arch(i386) || arch(x86_64)) && os(iOS)
  import Foo
#else
  import Bar
#endif

Also, since the flag is replaced with a 0 or a 1 by the swift preprocessor, if you directly use it in a if/else expression the compiler will raise a warning about unreachable code.

In order to work around this warning, see one of the other answers.

---

Related Topics