UJMLは異なるデバイス上で同じような動作をするプログラムを書くことを可能にします。 これは、個々のデバイス対応の処理のほとんどをUJMLが行い、かつ、プログラムをランタイム時にデバイスに適応させるために必要な UJML言語の各機能のサポートの有無を検出するための関数やエンティティ属性値を豊富に提供しているためです。

プログラムをデバイスに適応させる最初の手順は、デバイスコンテキストの取得です。 関連項目： デバイスコンテキストの取得方法。 コンテキストとはデバイスのハードウェアとソフトウェアの能力のことであり、 この情報を使用してプログラムの状態をランタイム時にデバイスに適応させます。 colors.ujml サンプルコードは、機能・性能が大幅に異なるデバイスに適応して 動作するUJMLプログラムの一例です。

デバイスに依存しないプログラムを書く次のステップは、ユーザインタフェースの設計です。 プログラム中で使用するビジュアル要素は、さまざまな種類の画面サイズやカラー対応、画像の種類に 対応させてください。 関連項目： 画面の解像度、 カラー対応、 画像サポート。 アプリケーションがオーディオ要素を使用する場合、ビジュアル要素同様に配慮が必要になります。 関連項目： 音声サポート。 画像やオーディオ要素の場合、同じファイルを複数のフォーマットで提供しなければならない場合もあります。 

またアプリケーションのモジュール化も重要な要素のひとつです。 アプリケーションの各機能をリンクまたはインクルードされるファイルに分割した、 高度にモジュール化されたアプリケーションは柔軟性に富み、他のデバイスへのポーティングを容易にします。 関連項目： UJMLアプリケーションの構造、 UJMLファイルの種類。 （Lunar Lander サンプルコード と Visual Elements サンプルコード は機能・性能が大幅に異なるデバイスに適応して動作するUJMLプログラムの一例です。） アプリケーションがUJMLモジュールをリンクする場合、同等の機能性を備えた複数のサブプログラムを提供し、 ランタイム時にデバイスのコンテキストに合わせてリンク先のモジュールを選ぶことも可能です。 

備考： UJMLアプリケーションのメモリ消費量はパーティションの使用数に応じて増えます。 この理由から、メモリ消費量やデバイスが提供しているメモリ量に対して、モジュール化の度合いをうまくバランスさせなければなりません。 インクルードされたファイルも消費メモリの増加につながりますが、 その増加量はリンクされるモジュールほどではありません。

デバイスが特定の機能をサポートしていなくても、ランタイム時にその他の機能で代用することが可能な場合があります。 例えば、楕円の描画をサポートしていないデバイスがあるとします。 その場合、プログラムの必要に応じて楕円の代わりに長方形や画像を使用する、 ビジュアル要素を使用しない、といった代替案が考えられます。 関連項目： ビジュアル要素。 

要素をどの要素で置き換えるべきか、あるいは置き換えをどのように行うべきかはアプリケーションによって異なります。

プログラムの動作に必須な機能をデバイスがサポートしていない場合、 プログラムの起動時に適切なエラーメッセージを表示し、プログラムの実行を中止すべきです。 このエラーメッセージには問い合わせ先の情報や、問題の切り分けに適切な情報を表示すべきです （デバイスの種類、プログラムのバージョン、不具合の種類など）。 プログラムがうまく動作しない場合も、ユーザーに良い印象を残すような配慮をすべきでしょう。

UJMLアプリケーションの動作対象のデバイスが一種類であっても、アプリケーションの設計時に デバイス依存性を無くすべきです。デバイスに対する依存性を無くすことは次のメリットをもたらします：

1. 新機種がリリースされた場合の、新機種対応の容易さ。
2. 市場が変化した場合における他のデバイスへのポーティングの容易さ。
3. モジュール化を促進することによる、コードの再利用性の向上。

アプリケーション設計は多くの場合、一種類ではなく複数の種類のデバイスに対応することを要求されます。 それならばデバイス依存性を可能な限り減らし、ありとあらゆるデバイスで動作するように設計してはいかがでしょうか。

UJMLアプリケーションの構造、 UJMLファイルの種類、 ビジュアル要素、 lunarlander.ujml、 Visual Elements サンプルコード