よく、「技術的には可能」とか「現実的に不可能」とか、修飾語付きで「可能」「不可能」ということもあるかと思います。今回は、いろんな「可能」「不可能」を分類してみました。
理論的に不可能
チューリングマシンの停止問題が有名な例ですが、ある種の問題については、どれだけリソースを使おうとも実現できないことが証明されています。
逆を返せば、そういったタスクでないものについては、リソースを用意すれば少なくとも解決できる可能性はある、ということになります。
物理的に不可能
こなすべきタスクが計算にとどまらない場合、当然ながら適切な入出力を行う機構が必要となります。「iPhone本体だけでA4の紙に必要事項を出力する」というのは、物理的に不可能です。
計算量的に不可能
理論的には解決方法があっても、それを実現するためのリソースが確保できない、ということも考えられます。たとえば、128ビットの暗号を総当たり攻撃するとした場合、1秒間に1兆通り試せたとしても500京年かかる計算となり、太陽の寿命のほうがずっと先に来てしまいます1。このように、現代のコンピューターで使われる暗号は総当たり攻撃に対する対策を、「現実的に試せるレベルを遥かに上回る組み合わせにする」という計算量的安全性によっています。
所定の枠内では不可能
企業の方針で不可能
App Storeで公開するアプリには、細かな基準が設けられていて、この基準に引っかかるアプリはリジェクトされ、一般公開ができません。また、APIによっては使い方にルールがある場合もあって、ルールに抵触するような使い方はできません。
セキュリティ的に不可能
App Storeの審査にもそのような側面がありますが、ブラウザ内などユーザーサイドで実行させる機能については、セキュリティ上可能なことに制約がかかっている場合が多いです。インターネット上のWebページから、ユーザーのディスクの任意のファイルを検索するようなことは、（ブラウザのセキュリティホールがないなら）不可能です。
プログラミング言語の記法としては不可能
多くのプログラミング言語はチューリング完全なので、機能的にはやりたいことを実現できるはずです。ただ、それをすんなり書けるのかどうかという問題はあります。
たとえば、C言語で「指定された名前の変数にアクセスする」というような実装は、（マクロで豪快に組めばもしかしたらそれっぽいことはできるかもしれませんが）基本的に不可能です。
技術的には可能だけど
さて、特定のことが実装可能とわかったとしても、それを実用できるかはまた別問題です。
法的・民事的な問題
他人の作ったコードを使うにはライセンスに従う必要がありますが、使いたい利用形態とライセンスが齟齬をきたした場合、当該のソフトウェアを使うことはできません。また、スクレイピングなどは最悪の場合業務妨害という犯罪になる危険もありますし、利用規約で禁止されているところに行えば損害賠償の対象ともなりえます。
リソースの問題
アメリカ政府が総力を上げたプロジェクトに動員できる、ハードウェア的・人的資源と、個人開発のそれでは、もちろん遥かに違ってきます。個人開発では自分の寿命以上に作成時間がかかって完結不能、ということも考えられます。
また、企業が何かしらの開発に取り組む場合、企業は営利目的の事業体なので、当然ながら何らかのメリット2を見込むこととなります。見込まれるメリットと開発コストが見合わなければ、プロジェクトは中止となることも考えられます。
実用性はあるのか
状況によっては、いちおう動かすことはできるものの、安定性・再現性がないために実用プログラムに組み込めないことも考えられます。逆に、すでに確立したライブラリがある分野では、同等のものを自分で書いても（学習目的としてはともかく）実用品まで持っていくのは労力の無駄遣いになってしまうケースもあります。